JP6412550B2 - System, method and apparatus for implementing data upload, processing and predictive query API publication - Google Patents

Description

Copyright Indication A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner, when the patent document or patent disclosure appears in the US Patent and Trademark Office patent file or record, is not objected to anyone by facsimile copy, but otherwise reserves all copyrights.

  Embodiments herein relate generally to the field of computing, and more specifically to systems, methods, and apparatus for performing data upload, processing, and predictive query API publication.

  The subject matter discussed in this background art section should not be assumed to be prior art, merely as a result of what is mentioned in the background art section. Similarly, it should not be assumed that problems mentioned in the background art section or associated with the subject matter of the background art section have been previously recognized in the prior art. The subject matter in the background section is merely representative of various approaches, and the various approaches themselves may also correspond to the claimed embodiments.

  Client organizations that have datasets in the database can benefit from predictive analytics. Unfortunately, there are no low-cost and scalable solutions in the market today. Instead, client organizations must hire technical experts to develop customized mathematical structures and predictive models, which are very expensive. As a result, client organizations without large financial instruments are simply locked out of the market and do not have access to predictive analytics capabilities for their data sets.

  Client organizations with financial tools to hire technical and mathematical experts to develop the necessary mathematical structures and predictive models suffer from the common problems of customized solutions. In particular, customized solutions are tailored to the specific problem at hand at a point in time, and as such, customized solutions can adapt to changes to underlying data structures. Without being able to adapt to changes to the type of data stored in the client's dataset, to meet the increasing and changing demands of the client's business and dataset as they grow over time Cannot be scaled up.

  The current state of the art can thus benefit from systems and methods for predictive query execution and use in on-demand and / or multi-tenant database systems, as described herein.

The embodiments of the present application are presented by way of example and not limitation, and will be more fully understood when considered in conjunction with the drawings with reference to the following detailed description.
1 depicts an example architecture in accordance with the described embodiments. FIG. 2 shows a block diagram of an example environment in which an on-demand database service may be used. FIG. 3 shows a block diagram of one embodiment of the elements of FIG. 2 and various possible interconnections between the elements. 2 shows a schematic representation of a machine in an exemplary form of a computer system according to one embodiment. Draw a tablet computing device and a handheld smartphone, each having integrated circuitry as described by the embodiments herein. FIG. 2 is a block diagram of one embodiment of a tablet computing device, smartphone or other mobile device in which a touch screen interface connector is used. Draw a simplified flow for probabilistic modeling. Fig. 4 illustrates an exemplary landscape in which a random walk may be performed. Draw an exemplary tabular data set. Describes means to derive motivation or causal relationships between observed data. An exemplary cross categorization is depicted in even more detail. Draw an evaluation of the convergence showing what was inferred versus ground truth. Draw the chart and graph of Bell serial number. Draw an exemplary cross-categorization of a small tabular data set. 1 depicts an exemplary architecture that implements data upload, processing, and predictive query API publication according to the described embodiments. FIG. 6 is a flow diagram illustrating a method for performing data upload, processing, and predictive query API publishing in accordance with the disclosed embodiments. 1 depicts an exemplary architecture for implementing a predictive query interface as a cloud service in accordance with the described embodiments. FIG. 6 is a flow diagram illustrating a method for implementing a predictive query interface as a cloud service in accordance with the disclosed embodiments. Fig. 4 illustrates the use of a RELATED command term according to the described embodiment. 1 depicts an example architecture in accordance with the described embodiments. FIG. 6 is a flow diagram illustrating a method according to disclosed embodiments. Fig. 4 illustrates the use of a GROUP command term according to the described embodiment. 1 depicts an example architecture in accordance with the described embodiments. FIG. 6 is a flow diagram illustrating a method according to disclosed embodiments. Fig. 4 illustrates the use of the SIMILAR command term according to the described embodiment. 1 depicts an example architecture in accordance with the described embodiments. FIG. 6 is a flow diagram illustrating a method according to disclosed embodiments. Fig. 4 illustrates the use of a PREDICT command term according to the described embodiment. Fig. 4 illustrates the use of a PREDICT command term according to the described embodiment. Fig. 4 illustrates the use of a PREDICT command term according to the described embodiment. 1 depicts an example architecture in accordance with the described embodiments. FIG. 6 is a flow diagram illustrating a method according to disclosed embodiments. 1 depicts an example architecture in accordance with the described embodiments. FIG. 6 is a flow diagram illustrating a method according to disclosed embodiments. Draw a graphical user interface (GUI) for displaying and manipulating tabular data sets with missing values by utilizing the PREDICT command term. Draw another view of the graphical user interface. Draw another view of the graphical user interface. 1 depicts an example architecture in accordance with the described embodiments. FIG. 6 is a flow diagram illustrating a method according to disclosed embodiments. Describes feature movements and entity movements in the index generated from the analysis of tabular data sets. Draw specialized GUI to query using history date. Draw a further view of the specialized GUI to query using history dates. Draw another view of the specialized GUI that makes up the prediction query. 1 depicts an example architecture in accordance with the described embodiments. FIG. 6 is a flow diagram illustrating a method according to disclosed embodiments. 6 depicts a pipeline change report according to the described embodiment. 6 depicts a waterfall chart using prediction data in accordance with the described embodiments. Draw a default interface after adding the first history field. Describes the default interface of the added custom filter in more detail. Draw another interface by default for added custom filters. 1 depicts an example architecture in accordance with the described embodiments. FIG. 6 is a flow diagram illustrating a method according to disclosed embodiments. Provides a chart that depicts predicted completeness versus accuracy. Providing a chart depicting the breakdown of opportunity reliability. Providing charts that depict opportunity win predictions. Provide charts that depict predictive relationships for opportunity scoring. Provide another chart depicting predictive relationships for opportunity scoring. Provide another chart depicting predictive relationships for opportunity scoring.

  Client organizations that want to perform predictive analytics and data mining on their datasets usually hire technical experts in an attempt to solve the problem at hand, explain the problem they want to solve, and then hire You have to apply your own mathematical structure to your expert by taking over your data.

  As an example, many years ago when computer engineers designed computer systems, it was also necessary to know how to map data to physical disks and be responsible for sectors, blocks, rotational speeds, and so on. Modern programmers are simply not concerned with these issues. Similarly, it is highly desirable for ordinary users to perform data analytics utilizing servers and sophisticated database technology without having to hire specialized experts. This way, you can free up resources and focus on other issues. The methodology described herein advances the field of predictive queries towards its goal by providing systems and methods for predictive query implementation and use in on-demand and / or multi-tenant database systems. The above methodology moves much of the mathematical and technical complexity to the hosted database system and hence out of the user's view. This reduces the learning curve for novice users and thus makes predictive technology available to a wider range of markets.

  Today, there is some machine learning ability. For example, current abilities can predictively answer questions such as "Is this person buying product x?" However, existing technologies are not practical when solving a wide range of problems. For example, a large healthcare company with large financial resources hires technical experts to develop customized analytics to solve specific problems based on the local healthcare database of the large healthcare company Would be able to. In contrast, small companies may not be able to simply hire such service providers because the cost of doing so is much heavier than the financial resources of small companies. In addition, as suggested above, even if an organization invests in such a customized solution, the solution is permanently fixed to the specific problem being solved, and new issues, new investigations, changing data types or data structures Cannot be scaled. As such, custom-developed solutions will become less consistent with new and constantly changing organizational business goals and will degrade over time. As business conditions, data and objectives change over time, as a result, this exemplary small company must give up solving current problems while hiring experts to develop custom solutions. Entities are forced to reinvest additional time and resources to update customized solutions and refurbish equipment. Neither outcome is ideal.

  Today, the services provided by technical experts in the field of analytics and predictive modeling provide customized solutions for customer specific data sets. The service does not provide the ability to be used by non-experts, nor does it provide a solution abstracted from a particular underlying data set. Instead, developed models require specialized training not only to implement but also to use, and such models are tied to the specific underlying data set for which the model was developed.

  Conversely, the methodology described herein is a broad range of query techniques, interfaces, databases, and other functionalities that cover a broad range of different levels of expertise and varying ranges of underlying data sets. Provide a basic architecture suitable for use by customer organizations and users.

  Salesforce.com provides on-demand cloud services to clients, organizations and end users, and behind these cloud services is a multi-tenant that allows users to have customized data, customized field types, etc. There is a database system. The underlying data and data structures are customized by these organizations for their specific specific needs. Nevertheless, the methodology described herein is not tied to any particular underlying database scheme, structure or content, and is therefore capable of analyzing and querying the above data sets and data structures.

  Customer organizations using the described approach will further benefit from the low cost of access enabled by the high scalability of the described solution. For example, a cloud service provider may choose to provide the above capabilities at no additional cost as part of the overall service it provides, or it may choose to provide additional capabilities for additional service fees. Good. In any case, the customer organization is not required to invest a large amount in front of a single customized solution as in the traditional approach. The above capabilities may be systematically integrated into the computing architecture of the cloud service, and its scalability does not require experts to adapt the solution to the customer for each specific client organization's data set and structure. Provides significant cost savings, thus allowing even small organizations with limited financial resources to benefit from predictive query and latent structure query techniques. Large companies with financial instruments can also benefit from the cost savings they can obtain and forecast for a wider range of research than has previously been possible using traditional methods Further benefits can be gained from the ability to provide query and latent structure query techniques.

  These and other benefits and more specific embodiments are described in more detail below. In the following description, numerous specific details are set forth, such as examples of specific systems, languages, components, etc., in order to provide a thorough understanding of various embodiments. However, it will be apparent to one skilled in the art that these specific details need not be employed to implement the embodiments disclosed herein. In other instances, well-known materials or methods have not been described in detail in order to avoid unnecessarily obscuring the disclosed embodiments.

  In addition to the various hardware components depicted in the figures and described herein, embodiments of the present application further include various operations described below. Operations described in accordance with such embodiments may be performed by hardware components or may be embodied in machine-executable instructions, which are general purpose or special purpose processors that are programmed using the instructions. Can be used to perform the above operations. Alternatively, the above operation may be executed by a combination of hardware and software.

  Embodiments of the present application further relate to an apparatus for performing the operations disclosed herein. The apparatus may be specially constructed for the required purpose, or it may be a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Also good. Such a computer program may be stored on a computer readable medium, such as, but not limited to, any type of disk, including but not limited to floppy disk, optical disk, CD-ROM and magneto-optical disk, read-only memory. (ROM), random access memory (RAM), EPROM, EEPROM, magnetic card or optical card, or any type of medium coupled to a computer system bus and suitable for storing electronic instructions.

  The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. A variety of general purpose systems may be used with programs in accordance with the teachings herein to prove the convenience for building a more specialized device to perform the required method steps. The required structure for a variety of these systems will appear as specified in the description below. In addition, embodiments of the present application are not described with reference to any particular programming language. It will be appreciated that various programming languages may be used to implement the teachings of the embodiments described herein.

  Embodiments of the present application may be provided as a computer program product or software that may include a machine-readable medium having instructions stored thereon, wherein the instructions are computer system (or other) to perform a process in accordance with the disclosed embodiments. Can be used to program electronic devices). A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (eg, a computer). For example, machine readable (eg, computer readable) media includes machine (eg, computer) readable storage media (eg, read only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical Storage media, flash memory devices, etc.), machine (eg, computer) readable transmission media (electrical, optical, acoustic), and the like.

  Any of the disclosed embodiments may be used together or together, either alone or in any combination. Various embodiments may be partially motivated by deficiencies in conventional techniques and approaches, some of which are described or suggested herein, The form does not necessarily address or resolve any of the above defects, but rather addresses only some of the defects, does not address any of the defects, or is not directly discussed May be addressed to various defects and problems.

  In one embodiment, the means for performing and using predictive and latent structure queries in a multi-tenant database system is performed in an application in a computing device, computing system or computing architecture, wherein the application is Cloud-based, where clients are able to communicate with remote computing devices such as remote clients over the public Internet, and thus clients utilize the functionality of remote applications that implement the ability to query and use predictive and latent structures Establish computing services.

  FIG. 1 depicts an exemplary architecture 100 in accordance with the described embodiment.

  In one embodiment, production environment 111 interfaces with a plurality of client devices 106A-C through host organization 110. In one embodiment, the multi-tenant database system 130 includes a relational data store 155 that stores a data set, for example, for a customer organization 105A-C or user. The multi-tenant database system 130 further stores an index 150 for the predictive query, which is provided, specified, or designated by the user and customer organization 105A-C, for example, by the user and customer organization 105A-C. -Generated from the data set stored for C.

  Multi-tenant database system 130 includes a plurality of underlying hardware, software and logic elements 120 that implement the database functionality and code execution environment within host organization 110. According to one embodiment, the multi-tenant database system 130 implements a non-relational data store and further implements a separate prediction database that stores an index 150 for prediction queries. The hardware, software, and logic elements 120 of the multi-tenant database system 130 are separate and distinguishable from multiple customer organizations (105A, 105B, and 105C), and the customer organization is connected to the host organization 110 via the network 125. By providing an interface in a communicable manner, a service provided by the host organization 110 is used. In this way, the host organization 110 can implement an on-demand service, an on-demand database service, or a cloud computing service for the subscribed customer organizations 105A-C.

  Host organization 110 receives input and other requests 115 from a plurality of customer organizations 105A-C over a network 125 (such as the public Internet). For example, an incoming PreQL query, prediction query, API request or other input may be received from the customer organization 105A-C and processed for the multi-tenant database system 130.

  In one embodiment, each customer organization 105A-C can be a separate and distinct remote organization, a group of organizations within the host organization 110, a business partner of the host organization 110, or a cloud computing service provided by the host organization 110. An entity selected from the group of subscribing customer organizations 105A-C.

  In one embodiment, the request 115 is received at a web server 175 within the host organization 110 or submitted to the web server 175. The host organization 110 can receive various requests for processing by the host organization 110 and its multi-tenant database system 130. An incoming request 115 received at the web server 175 can specify which service from the host organization 110 will be provided, which may be one of the customer organizations 105A-C, for example. Query requests, search requests, status requests, database transactions, processing requests, etc. for retrieving, updating or storing data for the purpose. Web server 175 is responsible for receiving requests 115 from various customer organizations 105A-C over network 125 and provides webs to end-user client devices 106A-C or machines that generate the data requests 115 described above. A base interface can be provided.

  Query interface 180 provides functionality to pass queries from web server 175 to multi-tenant database system 130 for execution against index 150 for prediction queries or relational data store 155. In one embodiment, the query interface 180 implements a PreQL application programming interface (API) or a JavaScript ObjectNotation (JSON) API interface and executes a query to the index 150 or relational data store 155 for predictive queries through the API. can do. The query optimizer 160 may, for example, perform query translation for other functionality that possesses sufficient information to design a query or PreQL query but lacks the logic necessary to actually build the query syntax. And perform optimization. The analysis engine 185 operates to generate a queryable index for the predictive query from a tabular data set or other data provided or specified by the user.

  Host organization 110 implements request interface 176 via web server 175 or as a stand-alone interface to receive request packets or other requests 115 from client devices 106A-C. Request interface 176 further supports returning response packets or other replies and responses 116 in the direction from host organization 110 to client devices 106A-C. According to one embodiment, the query interface 180 is specialized for executing a PreQL query or other predictive query against a database of the multi-tenant database system 130, such as an index for a predictive query at element 150. Functionality is used to implement the PreQL API interface and / or the JSON API interface. For example, the query interface 180 implements the above request 115 from the client device 106 by using an API call using a PreQL structured query term such as “PREDICT”, “RELATED”, “SIMILAR”, and “GROUP”. Can be operated to query a prediction database in the host organization 110. Furthermore, “UPLOAD” and “ANALYZE” API calls are available. These are those that upload a new data set to the prediction database 150 or define a data set and allow the analysis engine 185 to create an instance of the analysis of the data to support the above query. Is generated.

  FIG. 2 shows a block diagram of an example environment 210 in which an on-demand database service may be used. Environment 210 may include user system 212, network 214, system 216, processor system 217, application platform 218, network interface 220, tenant data storage 222, system data storage 224, program code 226, and process space 228. In other embodiments, environment 210 may not have all of the listed components and / or may have other elements in place of or in addition to the listed components above. May be.

  The environment 210 is an environment where an on-demand database service exists. User system 212 may be any machine or system used by a user to access a database user system. For example, any of the user systems 212 may be a handheld computing device, a mobile phone, a laptop computer, a workstation, and / or a network of computing devices. As shown in FIG. 2 (and in greater detail in FIG. 3), user system 212 can interact with an on-demand database service via network 214, which is system 216.

  An on-demand database service, such as system 216, is a database system made available to external users who need not necessarily be involved in building and / or maintaining a database system, but instead a database It may be possible to use the system when the user needs it (eg, for user demand). Some on-demand database services can store information from one or more tenants stored in a table of common database images to form a multi-tenant database system (MTS). Accordingly, “on-demand database service 216” and “system 216” are used interchangeably herein. A database image may include one or more database objects. A relational database management system (RDMS) or equivalent thereof can perform information storage and retrieval for database objects. Application platform 218 may be a framework that allows applications of system 216 to be executed, such as hardware and / or software, such as an operating system. In one embodiment, the on-demand database service 216 creates, manages, and executes one or more applications developed by the on-demand database service provider, and the user can connect to the on-demand database via the user system 212. It may include an application platform 218 that allows access to services or allows third party application developers to access on-demand database services via the user system 212.

  Users of user system 212 may differ in their respective capacities, and the capacity of a particular user system 212 may be determined as a whole by the permissions (permission levels) for the current user. For example, if a salesperson is interacting with system 216 using a particular user system 212, this user system has the capacity allocated to the salesperson. However, while an administrator uses the user system to interact with the system 216, the user system has a capacity allocated to the administrator. In a system with a hierarchical role model, users at one authorization level may have access to applications, data and database information accessible to users at lower authorization levels, but users at higher authorization levels. May not have access to specific applications, database information and data that can be accessed. Thus, different users will have different capabilities with regard to accessing and modifying application and database information, depending on the user's security or permission level.

  Network 214 is any network or combination of networks comprised of devices that communicate with each other. For example, the network 214 may be any of a local area network (LAN), a wide area network (WAN), a telephone network, a wireless network, a point-to-point network, a star network, a token ring network, a hub network, or any other suitable configuration. Can be one or any combination. The most common type of computer network in use today is the TCP / IP (Transfer Control Protocol and Internet Protocol) network, such as the global internetwork of the network often referred to as the “Internet” in capital “I” Yes, this network will be used in many of the examples herein. However, although TCP / IP is a frequently implemented protocol, it is understood that the networks that the claimed embodiments can utilize are not so limited.

  User system 212 communicates with system 216 using TCP / IP and can communicate at higher network levels using other common Internet protocols such as HTTP, FTP, AFS, WAP. In an example where HTTP is used, the user system 212 may include an HTTP client commonly referred to as a “browser” to send an HTTP message to an HTTP server in the system 216 and receive an HTTP message from the HTTP server. it can. Such an HTTP server may be implemented as the only network interface in the system 216 and the network 214, but other approaches may be used as well or instead. In some implementations, the interface in system 216 and network 214 includes load balancing functionality such as a round-robin HTTP request distributor to balance the load and distribute incoming HTTP requests evenly across multiple servers. Distribute. At least for users accessing the server, each of the plurality of servers has access to MTS data. However, other alternative configurations may be used instead.

  In one embodiment, the system 216 shown in FIG. 2 implements a web-based customer relationship management (CRM) system. For example, in one embodiment, the system 216 includes an application server that implements and executes a CRM software application and exchanges related data, code, forms, web pages, and other information with the user system 212. In addition, the related data, objects and web page contents are stored in a database and configured to be retrieved from the database. In a multi-tenant system, data for multiple tenants can be stored in the same physical database object. However, tenant data is typically kept logically separate from other tenant data unless such data is explicitly shared, so one tenant can access another tenant's data. It is arranged not to have. In certain embodiments, the system 216 implements applications other than or in addition to CRM applications. For example, the system 216 may provide tenant access for multiple hosted (standard and custom) applications, including CRM applications. User (or third-party developer) applications that may or may not contain CRMs may be supported by application platform 218, which creates applications and adds to one or more database objects. It manages storage and execution of applications in virtual machines in the process space of system 216.

  FIG. 2 shows an arrangement of elements of system 216, including network interface 220, application platform 218, tenant data storage 222 for tenant data 223, system 216 and possibly multiple tenants. System data storage 224 for accessible system data 225, program code 226 for implementing various functions of the system 216, and tenant specific processes such as executing applications as part of an application hosting service, And a process space 228 for executing MTS system processes. Additional processes that can be performed on system 216 include a database indexing process.

  Some elements in the system shown in FIG. 2 include conventional well-known elements, which are only briefly described here. For example, each user system 212 has a desktop personal computer, workstation, laptop, PDA, cell phone, or any wireless access protocol (WAP) capable of directly or indirectly interfacing with the Internet or other network. It may include a usable device or any other computing device. The user system 212 typically includes a browsing program such as an HTTP client, eg, a Microsoft Internet Explorer browser, Mozilla or Firefox browser, Opera, or a WAP-enabled browser in the case of a smartphone, tablet, PDA or other wireless device. Execute and a user of user system 212 (eg, a subscriber of a multi-tenant database system) accesses, processes, and views information, pages and applications available to it from system 216 via network 214 Enable. Each user system 212 is typically provided by a system 216 or other system or server, further including one or more user interface devices such as a keyboard, mouse, trackball, touch pad, touch screen, pen, etc. It interacts with a graphical user interface (GUI) provided on a display (eg, monitor screen, LCD display, etc.) by a browser in conjunction with pages, forms, applications and other information. For example, the user interface device may be used to access data and applications hosted by system 216, perform searches on stored data, and various GUI pages and other methods that may be presented to the user Can be allowed to interact with. As discussed above, the present embodiments are suitable for use on the Internet, which refers to a network of specific global internetworks. However, it is understood that instead of the Internet, other networks such as intranets, extranets, virtual private networks (VPNs), non-TCP / IP based networks, any LAN or WAN may be used.

  According to one embodiment, each user system 212 and all of its components are used by an operator such as a browser that includes computer code that is executed using a central processing unit such as an Intel Pentium processor. It is configurable. Similarly, system 216 (and its further instances if there are more than one MTS) and all of its components include applications that contain computer code to be executed using a central processing unit, such as processor system 217. The processor system 217 may include an Intel Pentium® processor and / or multiple processor units.

  According to one embodiment, each system 216 provides web pages, forms, applications, data, and media content to a user (client system 212) to support access by the user system 212 as a tenant of the system 216. Configured to do. As such, the system 216 provides a security mechanism to keep each tenant's data separately unless the data is shared. If more than one MTS is used, these MTSs may be placed close to each other (eg, in a server farm located on a single building or campus) or distributed remotely from each other. (E.g., one or more servers are located in City A and one or more servers are located in City B). As used herein, each MTS may include one or more logically and / or physically connected servers, either locally or distributed across one or more geographic locations. Further, the term “server” is intended to include computer systems including processing hardware and process space, and associated storage systems and database applications (eg, OODBMS or RDBMS), as is well known in the art. . It is understood that “server system” and “server” are often used interchangeably herein. Similarly, the database objects described herein may be implemented as single databases, distributed databases, collections of distributed databases, redundant online or offline backups or other redundant databases, etc. Processing intelligence associated with a distributed database or storage network.

FIG. 3 shows a block diagram of one embodiment of the elements of FIG. 2 and various possible interconnections between these elements. FIG. 3 also shows the environment 210. However, FIG. 3 further illustrates the elements of the system 216 and various interconnections in one embodiment. FIG. 3 illustrates that the user system 212 may include a processor system 212A, a memory system 212B, an input system 212C, and an output system 212D. FIG. 3 shows network 214 and system 216. 3 further shows that the system 216 includes tenant data storage 222, tenant data 223, system data storage 224, system data 225, user interface (UI) 330, application program interface (API) 332 (eg, PreQL or JSON API), PL / SOQL 334, storage routine 336, application setup mechanism 338, application server 300 ₁ -300 _N , system process space 302, tenant process space 304, tenant management process space 310, tenant storage area 312, user storage 314 and application metadata 316 It can be included. In other embodiments, the environment 210 may not have the same elements as those listed above and / or instead of or in addition to the elements listed above. You may have elements.

User system 212, network 214, system 216, tenant data storage 222, and system data storage 224 are discussed above in FIG. As shown by FIG. 3, the system 216 may include a network interface 220 (of FIG. 2) implemented as a set of HTTP application servers 300, an application platform 218, tenant data storage 222, and system data storage 224. In addition, a system process space 302 is shown and includes an individual tenant process space 304 and a tenant management process space 310. Each application server 300 may be configured for tenant data storage 222 and tenant data 223 therein, system data storage 224 and system data 225 therein so as to fulfill the request of user system 212. The tenant data 223 may be divided into individual tenant storage areas 312, and each tenant storage area may be either a physical arrangement and / or a logical arrangement of data. Within each tenant storage area 312, user storage 314 and application metadata 316 may be assigned similarly for each user. For example, a copy of the user's most recently used (MRU) item may be stored in the user storage 314. Similarly, a copy of the MRU item for the entire organization that is the tenant may be stored in the tenant storage area 312. UI 330 provides a user interface, and API 332 (eg, PreQL or JSON API) provides an application programmer interface to processes and resident in system 216 to users and / or developers at user system 212. Tenant data and system data may be stored in various databases, such as one or more Oracle ^™ databases.

  The application platform 218 includes an application setup mechanism 338 that supports the creation and management of applications by application developers, which are stored as metadata in the tenant data storage 222 by, for example, the save routine 336 and are tenanted by the subscriber. It may be executed as one or a plurality of tenant process spaces 304 managed by the management process space 310. Invocations for such applications may be coded using PL / SOQL 334, which provides programming language style interface extensions to API 332 (eg, PreQL or JSON API). Launch for an application may be detected by one or more system processes, which retrieve the application metadata 316 for the launching subscriber and execute this metadata as an application in the virtual machine To manage.

Each application server 300 may be communicatively coupled to a database system having access to, for example, system data 225 and tenant data 223 via various network connections. For example, an application server 300 _1, the network 214 (e.g., the Internet) may be coupled via, another application server 300 _N-1, may be coupled via a direct network link, the other application server 300 _N may be coupled by yet a different network connection. The transfer control protocol and the Internet protocol (TCP / IP) are typical protocols for communication between the application server 300 and the database system. However, it will be apparent to those skilled in the art that other transport protocols may be used to optimize the system depending on the network interconnect used.

  In certain embodiments, each application server 300 is configured to handle the requests of any user associated with any organization that is a tenant. Preferably, there is no server affinity for users and / or organizations for a particular application server 300 because it is desirable to be able to add and remove application servers from the server pool at any time for any reason. Accordingly, in one embodiment, an interface system that implements a load balancing function (eg, F5 Big-IP load balancer) is communicatively coupled between the application server 300 and the user system 212 to route requests to the application server 300. Distribute. In one embodiment, the load balancer routes user requests to the application server 300 using a minimum connection algorithm. In addition, other examples of load balancing algorithms may be used, such as round robin and observed response times. For example, in certain embodiments, three consecutive requests from the same user can lead to three different application servers 300, and three requests from different users can reach the same application server 300. In this way, the system 216 is multi-tenant and this system 216 handles the storage and access to various objects, data and applications across various users and organizations.

  As an example of storage, a tenant may be a company that employs a sales force where each salesperson uses the system 216 to manage his sales process. Thus, the user maintains all contact data, lead data, customer follow-up data, performance data, goal and progress data, etc. (eg, in tenant data storage 222) applicable to the user's personal sales process. be able to. In one example of an MTS deployment, all of the data and applications to be accessed, viewed, modified, reported, transmitted, calculated, etc. can be maintained and accessed by user systems that have nothing beyond network access, Users can manage their sales efforts and cycles from any of a number of different user systems. For example, if a salesperson visits a customer and the customer has internet access in that lobby, the salesperson can get important updates about this customer while waiting for the customer to arrive in the lobby.

  Regardless of each user's employer, each user's data may be separate from other users' data, but some data may be multiple users or all users for a given organization that is a tenant. It may be data on an organizational scope that is shared or accessible by. Thus, there may be some data structures managed by the system 216 allocated at the tenant level, while other data structures may be managed at the user level. An MTS can support multiple tenants, including tenants that can be competitors, so it can have a security protocol that keeps data, applications and application usage separate. In addition, redundancy, uptime, and backup are additional features that can be implemented in MTS because many tenants can choose to access MTS over maintaining their own unique system. In addition to user specific data and tenant specific data, the system 216 may further maintain system level data or other data usable by multiple tenants. Such system level data may include industry reports, news, posted messages, etc. that can be shared among multiple tenants.

  In certain embodiments, the user system 212 (which may be a client system) communicates with the application server 300 to request and update system level and tenant level data from the system 216. The data may require sending one or more queries to tenant data storage 222 and / or system data storage 224. The system 216 (eg, the application server 300 in the system 216) is configured with one or more SQL statements or PreQL statements (eg, one or more SQL or PreQL queries, respectively) designed to access the desired information. Is automatically generated. System data storage 224 may generate a query plan for accessing requested data from the database.

  Each database can generally be viewed as a collection of objects, such as a set of logical tables that contain data tailored to predefined categories. A “table” is a representation of a data object and may be used herein to simplify the conceptual description of the objects and custom objects described herein. It is understood that “table” and “object” may be used interchangeably herein. Each table typically includes one or more data categories that are logically arranged as columns or fields in a visible schema. Each row or record of the table contains an instance of data for each category defined by the field. For example, a CRM database may include a table that describes customers with basic contact information fields such as name, address, telephone number, fax number, and the like. Another table may describe a purchase order that includes fields of information such as customer, product, sales price, date, and the like. In some multi-tenant database systems, a standard entity table may be provided for use by all tenants. For CRM database applications, these standard entities may include a table of account, contact, lead and opportunity data, each of which may include predefined fields. It is understood that the term “entity” can also be used interchangeably herein with “object” and “table”.

  In some multi-tenant database systems, a tenant may be allowed to create and store custom objects, for example by creating custom fields for standard objects, including custom index fields, Alternatively, it may be possible to customize standard entities or objects. In certain embodiments, for example, all custom entity data rows are stored in a single multi-tenant physical table, which may include multiple logical tables per organization. It is transparent to the customer that multiple "tables" of customers are actually stored in one large table, or that customer data can be stored in the same table as other customer data.

  FIG. 4 shows a schematic representation of a machine 400 in an exemplary form of a computer system according to one embodiment in which any one or more of the methodologies discussed herein can be represented by a machine / computer system. An instruction set that causes 400 to execute can be executed. In another embodiment, the machine may be connected (eg, networked) to other machines in a local area network (LAN), intranet, extranet or public Internet. A machine may operate as a server in a client-server network environment or as a peer machine in a peer-to-peer (or distributed) network, as a server or set of servers in an on-demand service environment, at the capacity of the client machine. Specific embodiments of the machine are: personal computer (PC), tablet PC, set top box (STB), personal digital assistant (PDA), cellular phone, web appliance, server, network router, switch or bridge, computing system Or any form of machine capable of executing a (sequential or alternative) instruction set that specifies the actions to be performed by the machine. Furthermore, although only a single machine is illustrated, the term “machine” individually refers to an instruction set (or instruction sets) that performs any one or more of the methodologies discussed herein. Or should be considered to include any collection of machines (eg, computers) that run jointly.

  The exemplary computer system 400 includes a processor 402 and a main memory 404 (eg, read only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM)), flash Static memory such as memory, static random access memory (SRAM), volatile but high data rate RAM, etc.) and secondary memory 418 (eg, persistent storage including hard disk drives, persistent databases and / or Or a multi-tenant database implementation), which communicate with each other via a bus 430. Main memory 404 includes stored index 424, analysis engine 423, and PreQL API 425. Main memory 404 and its sub-elements are operable in conjunction with processing logic 426 and processor 402 to perform the methodologies discussed herein. The computer system 400 may additionally or alternatively embody server-side elements as described above.

  The processor 402 represents one or more general purpose processing devices such as a microprocessor, central processing unit, and the like. More specifically, the processor 402 is a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor that implements other instruction sets, Or it may be a processor that implements a combination of instruction sets. The processor 402 may further be one or more special purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, and the like. The processor 402 is configured to execute processing logic 426 for performing the operations and functionality discussed herein.

  Computer system 400 may further include a network interface card 408. The computer system 400 further includes a user interface 410 (such as a video display unit, liquid crystal display (LCD) or cathode ray tube (CRT)), an alphanumeric input device 412 (eg, a keyboard), and a cursor control device 414 (eg, a mouse). ) And a signal generator 416 (e.g., an integrated speaker). Computer system 400 may further include peripheral devices 436 (eg, wireless or wired communication devices, memory devices, storage devices, audio processing devices, video processing devices, etc.).

  Secondary memory 418 may include a non-transitory machine-readable or computer-readable storage medium 431 on which one or more of the methodologies or functions described herein may be implemented. Alternatively, multiple instruction sets (eg, software 422) are stored. Software 422 may reside entirely or at least partially in main memory 404 and / or processor 402 during its execution by computer system 400, and main memory 404 and processor 402 may also be machine-readable storage media. Can be configured. Software 422 may also be transmitted or received through network 420 via network interface card 408.

  FIG. 5A depicts a tablet computing device 501 and a handheld smartphone 502, each having integrated circuitry as described therein by the present embodiment. As depicted, each of the tablet computing device 501 and the handheld smartphone 502 includes a processor 504 integrated with a touch screen interface 503 in accordance with the disclosed embodiments.

  For example, in one embodiment, the system embodies a tablet computing device 501 or a handheld smartphone 502. The display unit of the system includes a touch screen interface 503 for a tablet or smartphone, and an integrated circuit that operates as a processor integrated with the memory is integrated into the tablet or smartphone. The integrated processor described above can be used to implement prediction and latent structure query implementations through on-demand and / or multi-tenant database systems such as cloud computing services provided over the public Internet as subscription services. One or more of the embodiments described in the specification are implemented. In one embodiment, the integrated circuit described above or the integrated processor of the depicted tablet or smartphone is a central processing unit (CPU) and / or graphics processing unit for a tablet computing device or smartphone. It is an integrated silicon processor that functions as a (GPU).

  Although the tablet computing device 501 and the handheld smartphone 502 may have limited processing capabilities, each may nevertheless host as a cloud-based service, such as the host organization 110 depicted in FIG. It is possible to take advantage of the prediction and latent structure query capabilities provided by the organization.

  FIG. 5B is a block diagram 500 of one embodiment of a tablet computing device 501, handheld smartphone 502, or other mobile device in which a touch screen interface connector is used. The processor 510 performs the main processing operations. Audio subsystem 520 represents hardware (eg, audio hardware and audio circuitry) and software (eg, drivers, codecs) components associated with providing audio functionality to the computing device. In one embodiment, the user interacts with the tablet computing device or smartphone by providing audio commands that are received and processed by the processor 510.

  Display subsystem 530 represents hardware (eg, display device) and software (eg, driver) components that provide a visual and / or tactile display to a user to interact with a tablet computing device or smartphone. Display subsystem 530 includes a display interface 532 that includes a particular screen or hardware device that is used to provide a display to the user. In one embodiment, the display subsystem 530 includes a touch screen device that provides both output and input to the user.

  The I / O controller 540 represents hardware devices and software components associated with user interaction. The I / O controller 540 may operate to manage hardware that is part of the audio subsystem 520 and / or the display subsystem 530. Further, the I / O controller 540 represents a connection point for additional devices that connect to a tablet computing device or smartphone, through which a user may interact. In one embodiment, the I / O controller 540 manages devices such as accelerometers, cameras, light sensors or other environmental sensors, or other hardware that can be included in a tablet computing device or smartphone. The input can be part of direct user interaction as well as providing environmental input to the tablet computing device or smartphone.

  In one embodiment, the tablet computing device or smartphone includes a power management 550 that manages characteristics associated with battery power usage, battery charging, and power saving operations. The memory subsystem 560 includes a memory device for storing information on a tablet computing device or smartphone. Connectivity 570 includes hardware devices (eg, wireless and / or wired connectors, and communication hardware) and software components (eg, drivers, protocol stacks) for tablet computing devices or smartphones to communicate with external devices. ). Cellular connectivity 572 may include, for example, a wireless carrier such as global system for mobile communications (GSM), CDMA (code division multiple access), TDM (time division multiplexing), or other cellular service standards. Wireless connectivity 574 includes non-cellular activity such as, for example, a personal area network (eg, Bluetooth), a local area network (eg, WiFi) and / or a wide area network (eg, WiMax), or other wireless communications. May be included.

  Peripheral connection 580 performs a peripheral connection as a peripheral device to another computing device (“TO” 582), and further a hardware interface for connecting the peripheral device to a tablet computing device or a smartphone (“FROM” 584) and Includes connectors and software components (eg, drivers, protocol stacks) and includes, for example, “docking” connectors that connect to other computing devices. Peripheral connections 580 include common or standard based connectors, including universal serial bus (USB) connectors, display ports such as mini display port (MDP), high definition multimedia interface (HDMI), Firewire, and the like.

  FIG. 6 depicts a simplified flow of stochastic modeling. Probabilistic modeling requires a series of choices and assumptions. For example, there may be a trade-off between fidelity and details with ease of handling. Assumptions define a consequential space that can be a possible hypothesis, and one such hypothesis actually occurs in the modeling view.

  For example, at element 601, the probabilistic modeling flow depicts an assumption that leverages the prior knowledge of 605. Flow proceeds to element 602, where element 602 has a hypothesis space that defines the possible outcome space of 606. The probabilistic modeling flow proceeds to element 603, which provides a hidden structure based on 607 learning derived from the defined space of 606 possible outcomes. The flow then proceeds to element 604, where the observed data is utilized by collecting information from 608 available sources, and then this observed data loops back to learning at element 607. To better inform the probability model recursively.

  The hidden structure at 603 is used to generate data. The hidden structure 603 and the resulting generated data can be considered a generative view. Learning 607 uses available sources of information and reasoning about hidden structures that may include specific modeling assumptions (“prior”) and observed data (“likelihood”); From the above, a combination of a priori and a likelihood can be used to draw a conclusion ("posterior").

  The above assumptions create a hypothesis space and further provide a means by which probabilities can be assigned to these assumptions, thus providing a probability distribution for the hypothesis given the observed actual data.

  The modeling assumptions implemented by the analysis engine to generate a queryable index define both a hypothesis space and a recipe for assigning a probability to each hypothesis given some data. This results in a probability distribution in which each hypothesis is a result, for which a great many available and possible outcomes can exist, each with different probabilities. In addition, there can be numerous hypotheses and finding the best hypothesis to explain the data is not a straightforward or obvious axiom.

  Thus, probabilistic reasoning represents the problem of how to search the hypothesis space available to find the hypothesis that gives the best explanation for the current data. The analysis engine described herein includes a wide range of methods including functionality that directly solves mathematics, functionality that utilizes optimization to find peaks in the hypothesis space, and functionality that performs random walks in the hypothesis space. To implement.

  Probabilistic modeling creates an assumption 601, and using this assumption, a hypothesis space 602 is defined. Given the observed data, probabilities are assigned to the hypotheses, and then inference is used to find out which of these explanatory hypotheses is valid and which is the best.

  FIG. 7 shows an exemplary landscape in which a random walk can be performed. Experts in this area do not agree on how to select the best hypothesis, but there are several preferred approaches. In the simple case, functionality can be solved directly using mathematics. Other optimization methods such as hill climbing and related products are also preferred. In certain described embodiments, the analysis engine utilizes a Monte Carlo method in which a random walk is performed through a hypothetical space. Random does not mean navigating inefficiently or lazily without aim, direction or purpose. In fact, efficiently navigating the vast space is one of the innovations that analysis engines use to improve the path taken by random walks.

  Consider a landscape of hypothesis space 703 that can perform a random walk. In this landscape, each axis is a dimension in the hypothesis space 703. A hidden value 2 is represented on the vertical axis in element 701 and a hidden value 1 is represented on the horizontal axis in element 702. An actual space may have many dimensions, much more than the two dimensions shown here for simplicity. The height of the surface formed by the random walk method is the probability of a hidden variable given the data and modeling assumptions.

  The search begins by taking a random step somewhere and somewhere, the search is kept if this step gets higher, the search is kept if this step gets lower, and sometimes the search is kept, sometimes The search is not kept and it is chosen to stay instead. The result is very useful because it is guaranteed to search the space in proportion to the true probability value. Through long runs, as can be seen from the example provided, two peaks occur, corresponding to each of the provided dimensions (eg, 701 and 702 in the two axes depicted). Conversely, a simple hill-climbing method will fail to produce a distinct peak that is caught at the top of one mountain. Thus, the above approach searches the entire hypothesis space, whereas conventional methods do not search in this way. Other innovations include additional intelligence about jumps and the ability to explore one or more dimensions at a time.

  FIG. 8 depicts an exemplary tabular data set. In tabular data, each row contains information about one particular entity, and each of the multiple rows is independent of each other. Each column contains a single type of information, and the data may be of a data type such as numbers, categories, Booleans, for example. Column types may be mixed and matched within a table, and the data type applied or assigned to any given column is uniform across all cells or fields within the entire column, The data type of one column does not limit any particular data type on any other column. Thus, the tabular data above matches very well to a single database table in a relational database that provides a tabular data set. Tabular data also matches the data frame in “R” well.

  In the exemplary table depicted, elements 802 form an entity where each of the rows is a mammal, and in element 801, each of the columns is a feature, characteristic, or variable that describes the mammal. Most of the columns are Boolean data types, but some are categories.

  Note that element 804 depicts an observed cell, ie, data is provided for the cell as opposed to element 803, which is an unobserved cell with no data available. Thus, an unobserved cell 803 is a null value, while an observed cell, whether the data is a Boolean, a category, a value, an enumeration element, or whatever is appropriate for the column data type. Has data entered in the field. All cells drawn in white or blank are unobserved cells.

The common assignment matrix for dimensions, C _ij = Pr [z _i = z _j ], gives the probability that dimensions i and j share a common cause and are therefore modeled by the same Dirichlet process mixture. The label indicates the consensus dimension group (probability> 0:75). These reflect attributes that share common causes and therefore co-variate, while the rest of the matrix correlates between these discovered causes, eg, mammals have wings or fly Capture rare, ungulates are not predators, and so on. Each dimension group picks out a different transverse row categorization (eg, vertebrates, birds, dogs, etc.).

  FIG. 9 depicts a means of deriving motives or causal relationships between observed data, such as the data provided in tabular form in FIG. In the exemplary data regarding mammals and their characteristics, it can be expected that some causal relationships can be derived appropriately. Conversely, if tabular data is modified to provide tea prices in China, such data is present and observed, but intuitively, mammals based on the observed data It is useful in some way for the resulting prediction made with respect to or does not hurt the prediction. Such unrelated data (eg, price of tea in China in a table describing mammals) represents noise and needs to be adapted. This is because real-world data frequently has noise and is not well structured. The analysis engine needs to find an appropriate motivation for prediction and not be misleaded by such data, even though noisy irrelevant data is actually “observed” in the provided data set. Real-world data is simple when scalable solutions are used that render appropriate predictions without requiring custom solutions to be developed manually for each and every dataset presented. It is not very clean and therefore presents a very practical problem. Thus, the analysis engine must employ a model that understands that some data is simply not important for a given hypothesis or predictive relationship. For example, some columns may not be important, or certain columns may carry redundant information. Thus, some columns may be predictively related and therefore may be grouped together, while others are not predictively related and are grouped separately as such. is there. Such a group of columns is called a “view”.

  Two distinguishable views are drawn. View 1 at element 905 results from contingency process 1 (element 903), and view 2 at element 906 results from contingency process 2 (element 904). Within each view 905 and 906, the rows are grouped into multiple categories. As shown, view 1 corresponds to feature 1-3 in elements 907, 908 and 909, and view 2 corresponds to feature 4-5 in elements 910 and 911. Each of the “features” of the respective views corresponding to the columns of the tabular data set depicted in FIG. 8 in the provided example is a characteristic for each mammal listed as an entity (eg, a row), Define variables or features.

  Then entity 1-2 is drawn in elements 901 and 902, and then each cell or field value is drawn in the view. In particular, the analysis engine has identified two column groupings, specifically, views 1 and 2 in elements 905 and 906, thus identifying the various predictive relationships that have been adapted for a particular view. Can do.

  FIG. 10A depicts an exemplary cross-categorization in even more detail. Using cross categorization, columns / features are grouped into views and rows / entities are grouped into categories. In FIG. 10A, view 1-3 is depicted, view 1 in element 1001 has 12 features, view 2 in element 1002 has 10 features, and view 3 in element 1003 has 8 features. have. Again, each view feature corresponds to a column from the provided tabular data set. It will be seen that in view 1 (element 1001), three entities are provided in three different categories of views. Entity 1 and 2 in elements 1005 and 1006 are both in the top category of view 1, entity 3 in element 1007 is in the intermediate category, and any of the entities (eg, rows) listed in detail are the top. It does not appear in the lower category. The blackened lines represent entities 1-3 (1005, 1006, 1007) and the arrangement has changed as you can see from view 2 (element 1002). View 2 has only 10 features and a single category that owns all three of the listed entities (rows) 1005, 1006, and 1007. Then, moving to view 3 in element 1003, there are four categories, and each of the three blackened entities (rows) 1005, 1006, and 1007 is in a distinguishable category.

  Element 1004 provides a zoomed-in drawing of view 3 and is identical to element 1003, but with additional details. Thus, in element 1004, each of the categories owns multiple entities, each of which represents an actual data point corresponding to a cell value from the table for the column actually listed by the view 3 category in element 1004. You will see that it has. For example, category 1 has 16 total entities, category 2 has 8 entities, category 3 has 4 entities, and category 4 has 2 entities. Then, category 3 is marked with an observed cell 1008 (for example, null value, missing data, blank representing unknown data, etc.) cell 1008 (marked with “X”) for which the data element is observed. Is still zoomed in.

  Single cross categorization is one particular way to slice and dice a tabular data table or data set. A particular type of processing is provided to produce the desired structured space, first in columns and then in rows. A probability is then assigned to each cross categorization, thus resulting in a probability distribution. More complex cross-categorizations that produce more views and more categories are feasible, but in practice these are unlikely to happen, so typically the underlying data makes them real Guaranteed only when supporting. More complex cross-categorization is supported but not used by default.

  Probabilistic modeling using clustering techniques including inference in Dirichlet process mixture models presents difficulties when the various dimensions are best explained by significantly different clustering. Nevertheless, the analysis engine embodiments described herein are required to describe the data using a separate Dirichlet process mixture model for each group of inferred partitions of the dimension. Overcoming the above difficulties through inference methods that automatically find the number of independent nonparametric Bayes models. Unlike Dirichlet process mixing (DP mixing), the described implementation is interchangeable across both rows (samples) and columns (new dimensions) of disparate data arrays, and thus has an infinite number of both samples and dimensions Any dataset as it approaches can be modeled. Through the use of the described algorithms that do not require preprocessing in certain instances to identify the true causal structure provided in the raw data set, improve efficiency and robustness.

  Clustering techniques are widely used in data analysis for segmentation problems in industrial and exploratory analysis in science and as a pre-processing step to improve the performance of further processing in distributed computing and data compression. Has been. However, as the data set becomes larger and more noisy, the assumption that a single clustering or a variance over clustering can account for all the variations in the observation is not feasible as a whole If not, it will not be very realistic.

  From a machine learning perspective, the above is an unsupervised version of the feature selection problem. Different subsets of measurement results will result in different natural clusterings of data as a whole. From the cognitive science and artificial intelligence perspectives, the above problems are reflected in the task of searching for multiple representations of data instead of a single monolithic representation.

  As a limiting example, a robust clustering method can ignore an infinite number of uniformly random or perfectly deterministic measurements. The assumption that a single nonparametric model must account for all dimensions is partially reasonable with respect to the accuracy problem that Dirichlet process mixing often faces in high dimensional settings. A classifier based on Dirichlet process mixing via classification conditional density estimation highlights the above problem. For example, discriminative classifiers can assign small weights to noisy or deterministic and hence unrelated dimensions, while generative models must account for these. If there is sufficient irrelevance, the generative model ignores the dimensions associated with classification in this process. Combined with slow MCMC convergence, the above difficulties constrain the use of nonparametric Bayesian methods in many applications.

  To overcome the above limitations, an unsupervised cross-categorized learning approach is utilized for clustering based on MCMC inference in a new nested non-parametric Bayes model. This model can be viewed as a Dirichlet process mixture over columns or dimensions of a Dirichlet process mixture model over sampled data points or rows. Conditioned on the dimensional partition, the analysis engine model is reduced to an independent product of DP mixture, but the number and domain of the dimensional partition and thus independent non-parametric Bayesian models are Further inference from the data.

  Standard feature selection results in a situation where the dimension partition has only two groups. The model described is thought to be cumbersome due to the combinational explosion of latent variables, both model selection and deterministic approximation, so changing the number of latent variables when the dimension partition changes, MCMC Use an approach.

を生成する
（ｂ）超パラメータαを用いて（あいまいな超事前分布からのαを用いて）中華レストラン過程（Chinese restaurant process）から次元ｄについてのモデル割り当てＺ_ｄを生成する
２．次元区画｛Ｚ_ｄ｝の中の各グループｇについて：
（ａ）各々のサンプリングされたデータ点（又は行）ｒ∈Ｒについて、超パラメータα_ｇを用いて（あいまいな超事前分布からのα_ｇを用いて）中華レストラン過程からクラスタ割り当てＺ_ｒ ^ｇを生成する
（ｂ）次元｛Ｚ_ｄ ^ｇ｝の上記グループについての行区画の中の各クラスタｃについて：
ｉ．各次元ｄについて、適切な事前分布と
［外２］

とからコンポーネントモデルパラメータ
［外３］

を生成する
ｉｉ．このコンポーネント（ｄ∈ＤについてＺ_ｒ ^{ｚ ｄ}＝ｃ）の中の各データセルｘ_{（ｒ，ｄ）}について、その値を適切な尤度と
［外４］

とから生成する。 The hypothesis space captured by the model described has a significantly different structure than the hierarchical Dirichlet process and is hyperexponentially larger than the hypothesis space of the Dirichlet process mixture. The generation process considered as a model for a heterogeneous data array with a fixed type of N rows and D columns and randomly missing values can be described as follows:
1. For each dimension d∈D:
(A) From appropriate hyper-prior to hyperparameters
[Outside 1]

(B) Generate a model assignment Z _d for dimension d from the Chinese restaurant process using the hyperparameter α (using α from the ambiguous hyperprior distribution). For each group g in the dimension partition {Z _d }:
(A) For each sampled data point (or row) rεR, using the hyperparameter α _g (using α _g from the ambiguous hyper prior distribution), the cluster assignment Z _r ^g from the Chinese restaurant process Generate (b) for each cluster c in the row partition for the group of dimensions {Z _d ^g }:
i. For each dimension d, an appropriate prior distribution and [Outside 2]

And component model parameters [outside 3]

Generate ii. For each data cell x _{(r, d) in} this component (Z _r ^{z d} = c for dεD ₎ , its value is taken as the appropriate likelihood and [outside 4]

And generate from

In the stochastic theory, the Chinese restaurant process is a discrete-time stochastic process whose value at any positive integer time n is a partition B _n of the set {1, 2, 3, n}, and its probability distribution is Determined as follows: at time n = 1, a trivial partition {{1}} is obtained with probability 1, and at time n + 1, element n + 1 is added to one of the blocks of (a) partition B _n Where each block is chosen with | b | / (n + 1) and | b | is the size of the block, or (b) is added to partition B _n as a new singleton block with probability 1 / (n + 1), One of them. The random partitions thus generated are labeled {1,. . . , N} are interchangeable in the sense that they do not change the distribution of the partition, and the principle of n−1 partitions obtained by removing element n from the random partition at time n is the random partition at time n−1. It is consistent in the sense that it is the same as the principle.

This model encodes a recursive bias that is quite different from the Indian buffet process (IBP) adaptation of the Chinese restaurant process, and in contrast to the features that are typically added and combined, a heterogeneous data vector. Discover independent systems of categories across. It is also beneficial to contrast the asymptotic performance of the model with the asymptotic performance of Dirichlet process mixing. Dirichlet process mixing has an arbitrarily large asymptotic performance when the number of samples approaches infinity. In other words, Dirichlet process mixing can model any distribution over a finite dimensional vector given enough data. However, if the number of dimensions (or features) is made infinite, it is no longer asymptotically consistent. That is, a series of data sets is generated by sampling the first K ₁ dimension from the blend, and then adding K ₂ >> K ₁ dimension, which is made a constant value (eg tea price in China) when this series of data sets will eventually be forced to only model dimension K _2, it will ignore the statistical structure of the first K _1. In contrast, a model implemented through an analysis engine according to the described embodiment has asymptotic performance in terms of both the number of samples and the number of dimensions and is infinitely interchangeable with respect to both quantities. .

  As a result, models implemented through the analysis engine are not self-consistent across a subset of measured variables and therefore face noisy, missing and unrelated measurement results, or confounding statistical signals. The robustness that should be considered can be enjoyed. This is because in demographic settings and in high-throughput ecology, noisy or theoretically covariant but orthogonal measurements are mode values, and each data vector is real-world It is particularly useful when it comes from multiple independent generation processes.

  The algorithms and models implemented through the analysis engine are built on a general purpose MCMC algorithm for stochastic programs that scales linearly with each iteration in the number of rows and columns, all Including inferences over hyperparameters.

  FIG. 10B depicts an assessment of convergence, with more than 1000 MCMC runs (200 iterations each) using variable data set sizes (up to 512 × 512, each taking 1-10 minutes) and true dimensional groups. ) Shows inferred versus ground truth, providing a joint score for. The majority of the points are near the ground truth dashed line, indicating reasonable convergence. Perfect linearity is not expected due in part to the subsequent uncertainty.

  Large scale implementations take advantage of conditional independence in the model described. The model described is inherently free of parameters (eg, using an inappropriate uniform hyper-predistribution) and produces noisy and / or irrelevant measurement results generated by multiple interaction sources. Because it is robust to and supports heterogeneous data that is optionally sparsely observed, it may be widely applicable in exploratory data analysis. In addition, the performance of the MCMC algorithm utilized is a cross-sectional approach where the described approach to nesting latently variable models in Dirichlet processes across multiple dimensions converges robustly and rapidly over a wide range of nonparametric Bayesian methods. Suggests that it may be applied to generate various deformations.

  An API associated with prediction and latent structure query capabilities is a prediction database that finds the cause behind the data and uses this cause to predict and explain the future in a highly automated manner that is not available to date Is used. In this way, any developer can perform scientific research on a dataset without the need for custom programming and consultation by mathematicians and other such experts. The above causes are revealed by the latent structures and relationships learned by the analysis engine.

  Prediction and latent structure query capabilities have been successful by searching an extensive hypothetical space of all possible relationships that exist in the data set using an evolved Bayesian machine learning algorithm, thus providing developers with: Up-to-date inference performance and prediction accuracy for a fairly wide range of real-world data sets without any manual parameter tuning; including very high-dimensional data with hundreds of thousands or millions of columns or rows Scalability to large datasets; fully flexible predictions (eg, values for any subset of columns, arbitrary values, without any retraining or adjustment required by conventional approaches when data or queries change) Predictable given the values for the other subsets. Prediction and latent structure query capabilities further provide quantification of the uncertainty associated with the prediction, since the system is built around a Bayesian probabilistic model sufficiently. For example, the user can be presented with a confidence measure or score, such as a resulting query, ranking, sorting, etc., according to the quality of the rendered prediction.

  The described application, built on predictive and latent structure query capabilities, understands healthcare spending from predicting heart disease, evaluates business opportunities, and “closes” these business opportunities successfully ( For example, the likelihood of successfully balancing sales, contracts, etc.).

  As mentioned above, one of the problems with real-world data is that different types of data tend to be mixed together and difficult to handle. For example, structured data and unstructured data are commonly blended together. Data can be inadvertently updated and therefore filled with errors. Data elements (eg, cell or field values) are missing quite often, resulting in null values or unknown data points. Real-world data is almost always lacking in documentation and is therefore not well understood even by organizations that collect and maintain the above data. Therefore, the data has not been utilized to the maximum benefit of the data for the organization. The user of the data can also measure the wrong one and the same one in ten different ways.

  These problems arise for a variety of reasons. Perhaps there has been no DBA (database administrator) in the organization, or the DBA has left, and a 10-year accumulation layer of data has been built. Alternatively, the individual responsible for data entry and maintenance simply induces errors and mistakes through natural human behavior. All of the above is very realistic and is common to “real world” data found in production databases for various organizations, as opposed to clean small data sets that may be found in research or test settings. It is a problem.

  Thus, an analysis engine described herein that generates a queryable index with support for predictive queries must accommodate “real world” data as it actually exists in nature. The analysis engine understands the meaning of the data as it exists in the real business and does not require a clean data set or data that follows the ideal structure of how the data looks. The analysis engine generates an index that can be queried in real time for many different questions regarding many different variables. The analysis engine is capable of obtaining hidden structures in the above data, ie what variables are important and what segments or groups are in the data. At the same time, the analysis engine produces reliable predictive relationships, ie, low predictive quality misleading relationships and predictions and erroneous relationships and predictions are avoided through models utilized by the analysis engine. Preferably, the analysis engine does not reveal that it is not true, and does not report ghost patterns that may be present in the first data set or sample but do not generally support it. These desired characteristics are very difficult to achieve with customized statistical analysis and customized predictive modeling, and are not heard at all in any automated system available on the market today.

  When making a prediction, it is helpful to inform the user additionally whether the user may trust the result. That is, how confident the system is is present in the results by quantitative measures such as confidence indicators, confidence scores, confidence intervals and the like. Sometimes the system needs to respond literally by indicating "I don't know", rather than providing a predicted result of low confidence quality or a result below the minimum confidence threshold set by the user. It can be. Thus, the system is confident that the system is confident that the result will indicate to the user that the answer is, for example, 1 or between 1 and 10 or between negative infinity and positive infinity. May be returned so that each is defined quantitatively.

  Using probabilities, the system can advise the user, for example, that they are 90% confident that the answers they give are real, accurate, and correct, or alternatively, the system can simply provide sufficient data It may return a result indicating that it is missing and therefore not enough to know to render the prediction.

  According to certain embodiments, the analysis engine utilizes a specially customized probability model based on basic cross-categorization modeling applied to tabular data. Conventionally available cross-categorization models provide a good start, but can still be improved. For example, in a conventionally available cross-categorization model, the formula cannot be executed. In contrast, the analysis engine implementation described herein overcomes this deficiency in the prior art by allowing the above formula execution. In addition, cross-categorization models that have been available in the past have relied on matching data with models chosen to understand hidden structures as well as building probability indices. However, it has proven to be very complex to require the model to be matched to the specific data set to be analyzed, and users of these traditional cross-categorized models can be assigned to any given data set. On the other hand, high mathematical knowledge and probabilistic theory understanding were required to simply select and implement an appropriate model, and the general public was not able to use such a model in practice. If the tools available are too complex for most people to use, the tools are practically inaccessible to most people, regardless of their presence and availability.

  Analysis engines with the support technologies described herein (eg, cloud computing interface and PreQL structured query language) are distributed processing, job scheduling, persistence, checkpointing, and user-friendly APIs or front-ends It aims to solve the above problem by providing a service including an end interface. The above service accepts general user questions and queries through the PreQL query structure, which significantly reduces the learning curve and eliminates the specially required knowledge required to use the above service To do. Other specialized front-end GUIs and interfaces are further described to solve specific use cases for users and provide other simple interfaces to complex probability problems, thus Furthermore, it reduces the complexity even for the specific use cases mentioned above.

  Specific examples of use cases that are specifically implemented include: “Which resolved support case is closest to this case?” Or alternatively, “Which pre-winning sales opportunity is similar to this current opportunity? An interface that finds similar entities may be mentioned to allow the user to ask the dataset for questions such as “?”. Thus, the interface described above presents current sales opportunities based on past wins that the user solves the current problem based on similar past solutions or has a similar stochastic relationship with the current opportunity profile. Allows a user to query a user-owned data set for answers that can help win.

  Specific use case implementations further assist users in predicting unknown values. This may be due to missing data from data sets input in other ways, such as null values, or to predict values that cannot be known because they will remain in the future. For example, an interface might say "Will you win this opportunity?" Or "How much would you win if you win this opportunity?" Or "How much will I sell in this quarter?" Help the user predict the answer to the question and the associated confidence score or indication.

  Other use cases ask questions such as “What should I do next to advance this opportunity?” Or “What additional products should I suggest to this customer?” Can help guide user decision making and behavior. These tools can be directly useful to salespeople, but can also be useful to sales managers and other business individuals who are affected by the sales process.

  In particular, a prediction quality indication may be provided along with the prediction for the above question, or simply a prediction value may be provided for the missing data. These predictive quality indications may be referenced by confidence scores, predictive quality indicators, and other names, but generally speaking, the above indications are likely to give a given event or value or are true. It is a reflection of the probability that Although there are many perspectives, probabilities can be stated as statements by the observer regarding the degree of trust in past, present or future events. Timing is not important. Thus, probabilities can be viewed as statements of trust such as “How likely is an event to occur?” Or “How likely is a value to be true for this data set?”

  Probabilities are needed because we can't be 100% sure about what will happen or in some cases what will happen, and as such, the prediction is uncertain . So what is uncertainty? Observers do not know for certain that the event will occur, regardless of the degree of confidence that such event has occurred, has occurred, or will occur in the future, as described above.

  Probabilities are assigned in the context of knowledge or information. Different observers may have different knowledge and assign different probabilities to the same event, or assign different probabilities even when both observers have the same knowledge. Probability, as used herein, may be defined as a number between “0” (zero) and “1” (one), where 0 is on one end of the continuum. It means that it is certain that no event will occur, 1 means that it is certain that an event will occur on the other end of the same continuum. Both ends are interesting because they represent a complete lack of uncertainty.

  Probability ties credit to one event. A probability distribution ties trust to every possible event, or at least every event that should be considered in a given model. Choosing a consequence space is an important modeling decision. Summed over all consequences in space is the total probability, which should be a sum of "1". That is, according to the model, one of the consequences must occur. Probability distributions are a convenient mathematical form that helps to summarize system trust at various probabilities, but choosing a standard distribution is a modeling choice where all models are wrong but some are useful. is there.

  For example, consider the Poisson distribution, which is a good model when an event can occur zero or more times in a time span. The result space is the number of times an event occurs. The Poisson distribution has a single parameter, which is the rate, ie the average number of times. Its mathematical form has some good attributes, such as the sum of all non-negative integers being defined as 1.

  The standard distribution is well known and there are many examples other than the Poisson distribution. Each such standard distribution includes a specific set of assumptions, such as a specific outcome space, a specific method of assigning probabilities to outcomes. When working with these assumptions, you will begin to understand why some are comfortable and frustrating, even if they are not completely harmful to the problem at hand.

  However, the distribution may be even more interesting. The analysis engine uses a distribution that moves beyond the standard distribution with specially customized modeling, thus allowing for a more complex outcome space and thus a more complex way to assign probabilities to outcomes. Make it even more possible. For example, a mixed distribution combines many simpler distributions to form a more complex distribution. A mixture of Gaussian distributions that model arbitrary distributions may be employed to create more intricate mathematical relationships while still assigning probabilities to outcomes.

  Using a more complex consequence space, the Mondrian process provides a means of defining a distribution on a k-dimensional tree and partitioning a quadrilateral or legislature. The resulting space is defined by all possible trees, and the resulting partition looks like the famous painting from which this process is derived. The resulting outcome space is more structured than the space provided by the standard distribution. Traditional cross-categorization models do not use Mondrian processes, but use structured consequence spaces. The analysis engine described herein utilizes a Mondrian process in selected embodiments.

  No matter how complex the resulting outcome space is, the analysis engine is always capable of assigning reasonable probabilities for each and every outcome within the defined outcome space. Each assigned probability represents the degree of “trust”, or an evaluation of the probabilistic quality of the analysis engine, according to the model applied for the likelihood of a given outcome, where all over all possible outcomes of the space The total probability is “1”.

  Probabilistic models are used to allow computers to "think logically" automatically and systematically according to the model used, even in the presence of uncertainty. Probability is best in a systematic way by combining analysis sources with variable information sources, even when the information is ambiguous, uncertain or ambiguous, as is very common in real-world data. To reach the possible answer of.

  An unbounded categorical data type is further used to model a category column where new values not found in the data set may appear. For example, most sales opportunities for database services will replace one of a handful of existing existing systems, such as the Oracle implementation, but new opportunities have never been seen in the data It may be to replace a new system. The absence of this new value in the data set in advance does not mean that this is not valid. As such, this new value may be a limited set of recognized values (eg, an enumerated set) for a typed column, even if the value has not been seen before. ) Is allowed to be entered. From a modeling point of view, the system states that if a small number of values are ever seen in an unbounded categorical data type, new values are unlikely to be seen in the future. If a large number of values are seen in an unbounded category data type, a new value is likely to be seen in the future. "

  FIG. 11 depicts a series of bell number charts 1101 and a graph 1102. The number of bells defines the number of partitions for n labeled objects, and this number grows very rapidly, as can be seen from the graph 1102 on the right. A handful of objects are illustrated in the left chart 1101. Graph 1102 draws n up to 200, yielding 1e + 250, or a number having 250 zeros. Now consider a large data set available in a cloud computing multi-tenant database system that can easily yield a data set of interest having thousands of columns and millions of rows. These datasets are not just the number of bells drawn above, but rather the bell “square”, which makes us aware of the number of scales that are completely unthinkable by human intelligence and experience. .

  The above numbers are large enough to help you think in the following context. The dashed line in element 1103 near the bottom of graph 1102 represents the approximate total number of web pages currently indexed by Google. Google only needs to search for the 17th number of bells. However, the total space is unimaginably large, and it is simply impossible to search for it. In addition, the probability landscape is both large and bumpy rather than flat or concave, so forceful processing will not work, and a simple hill-climbing methodology is also not sufficient.

  FIG. 12A depicts an exemplary cross categorization of a small tabular data set. Here, this exemplary cross-categorization consists of view 1 at element 1201 and view 2 at element 12020. Each of the views 1201 and 1202 includes both features or characteristics 1204 (drawn as columns) and entities 1203 (drawn as rows). Segments of each of views 1201 and 1202 with white space between entities 1203 (eg, rows) are categories 1210, 1211, 1212, 1213 and 1214 in view 1 in element 1201, and in view 2 in element 1202. Categories 1215, 1216, 1217 and 1218. Refer back to FIG. 10A for further examples and explanations regarding views and categories.

  Views 1201 and 1202 pick out a subset of features 1204 (eg, columns) available for the dataset, and each category 1210-1218 within each view 1201 and 1202 represents a subset of entities 1203 (eg, rows). Picked up. Each column contains a single type of data, so each vertical strip within a category contains data typed as numbers, categories, etc. With this exemplary cross-categorization breakdown, the basic standard distribution can be used more efficiently.

  In certain embodiments, each collection of points is modeled using a single simple distribution. A basic distribution that works well for each data type may be pre-selected, and each selected basic distribution is only responsible for describing a small subset of the actual data for which the basic distribution is specifically useful. . Then, using the mixed distributions discussed above, the basic distributions are combined so that many simple distributions are utilized to create more complex distributions. The cross-categorization structure is used to shred a data table into a large number of pieces, where each piece is modeled using a simple distribution selected based on the applicable data type and the data A large mixture distribution is produced.

  Referring back to the tabular data set describing the particular mammal depicted in FIG. 8, in response to the simplified cross-categorization model shown in FIG. 12A with two views 1201 and 1202, the above It can now be seen in FIG. 12A how the tabular data looks.

  The right view 1202 includes habitat and feeding style features 1204 (columns), and entities 1203 (rows) include terrestrial mammals (from Persian cats to Zebra) and marine predators ( Dolphins to walrus) and baleen whales (blue whale and humpback whale only) and remote amphibious beavers (eg, both land and water) The beaver is divided into four categories 1215-1218.

  The left view 1201 has another division in which primates are grouped together, large mammals are grouped together, herbivores are grouped, and then some strange data at the bottom. Are grouped together (bats and seals). Even for a small data set, it is easy to imagine various ways to partition the data. However, the data is ambiguous and there is no perfect or apparently correct division. For all groupings that appear to fit correctly, a particular grouping may appear awkward or poorly fitted. The systematic process of applying various models and assumptions creates trade-offs and compromises, which is why even experts cannot agree on a single approach. Nonetheless, the means described herein allow the above trade-offs and compromises to be systematically exploited by the analysis engine to the extent and scale that a human expert cannot simply do. Allow use of various available models.

  For example, the results from the analysis engine are not limited to a single cross-categorization model or breakdown. Instead, a collection of categorization models is utilized, which when used together helps reveal the hidden structure of the data. For example, if all the resulting categorizations were the same despite the use of various categorization models, simply there was no ambiguity in the data. However, the above results do not occur with real-world data, despite the theoretical possibility. Conversely, if all the resulting categorizations are all completely different, then the analysis engine has not found any structure in the data. This can happen from time to time, and therefore the analysis engine will need some further post-processing, such as adding additional noise, to capture uncertainty. However, typically the middle thing happens, and some interesting hidden structures are revealed to the analysis engine from the data through the application of a collection of categorized models that are selected and utilized.

  The specially customized cross-categorization implementation represents the analysis engine processing and logic core, which is intentionally hidden from the end user due to its use and complexity. Rather than accessing the analysis engine core directly, the user instead has access to APIs, PreQL, JSON, and other specialized utility GUIs and interfaces implemented by, for example, the query interface depicted in element 180 of FIG. Through a less complex interface. Despite this abstraction layer from the core of the analysis engine, the user still benefits from the functionality described without having to have a highly specialized understanding of mathematics and probability.

  According to certain embodiments, the analysis engine further applies inferences and searches against the developed probability landscape by utilizing Monte Carlo methodologies in certain examples. For example, as illustrated by the number of bells, the space to travel may be large. Thus, one approach is to simply start somewhere, anywhere and calculate the probability of an event, consequence or value at that location in the available space. Then another location in this space is selected and the probability is calculated again. Then, in a repetitive manner, comparing the probabilities until a specific amount of time or processing expires, or until a sufficient quality result (eg, probability of exceeding a threshold or confidence score) is achieved, the new location Is determined, the probabilities are calculated, compared, selected or discarded, and a decision is made whether to keep the new location or instead keep the previously found location.

  FIG. 12B depicts an exemplary architecture that implements data upload, processing, and predictive query API publication in accordance with the described embodiments. Specifically, customer organizations 1205A, 1205B and 1205C are depicted, each comprising client devices 1206A, 1206B and 1206C, including client devices 1206A, 1206B and 1206C sending requests and receiving responses. Ability to interface with host organization 1210 via network 1225. There is a request interface 1276 within the host organization 1210, which may optionally be implemented by the web server 1275. The host organization further includes a processor 1281, memory 1282, API interface 1280, analysis engine 1285, and multi-tenant database system 1230. There is execution hardware, software, and logic 1220 in the multi-tenant database system 1230, and the execution hardware, software, and logic 1220 are shared across multiple tenants of the multi-tenant database system 1230 and the prediction database 1250. The ability to store an index generated by the analysis engine to facilitate returning a prediction result set in response to a prediction query or latent structure query executed against the prediction database 1250.

  According to one embodiment, the host organization 1210 runs a system 1211 having at least one processor 1281 and memory 1282, which receives as input a tabular data set that is described herein. It is possible to execute received prediction and latent structure queries on the indexes processed by the methodology described in the document and stored by the prediction database 1250.

  According to one embodiment, there is a system 1211 running within a host organization 1210 that includes at least a processor 1281 that executes instructions stored in the memory 1282 of the system 1211 and a plurality of rows and columns. A request interface 1276 that receives as input a tabular data set 1249, an analysis engine 1285 that processes the data set 1249 and generates an index 1251 that represents a stochastic relationship in the rows and columns of the data set 1249, and A prediction database 1250 that stores the index 1251, a request interface 1276 that further receives requests for prediction and / or latent structure queries 1253 for the index stored in the prediction database 1250, and a prediction result set based on the request. It includes an application programming interface (API) 1280 to query the index stored in the prediction database 1250 for preparative 1252, and in this system, the request interface 1276 returns the predicted result set 1252 in response to the received request.

  In one embodiment, the system 1211 described above further includes a web server 1275 that implements the request interface 1276. In one such embodiment, the web server 1275 receives as input from one or more client devices 1206A-C in the plurality of customer organizations 1205A-C that interface with the host organization 1210 via the network 1225. Receive access request. According to one such embodiment, the system 1211 further includes a multi-tenant database system 1230 with predictive database functionality to implement a predictive database, and each customer organization 1205A-C is separate and distinguishable. An entity selected from a group consisting of a remote organization, an organizational group within the host organization, a business partner of the host organization, or a customer organization that subscribes to a cloud computing service provided by the host organization.

  FIG. 12C is a flow diagram illustrating a method 1221 for performing data upload, processing, and predictive query API publication in accordance with the disclosed embodiments. The method 1221 may be performed by processing logic, which includes hardware according to a system, apparatus and method for performing data upload, processing, and predictive query API publishing as described herein. Processing device to perform various operations such as circuit, dedicated logic, programmable logic, microcode, etc.), software (eg, send, send, receive, execute, generate, calculate, store, publish, query, process) Instructions executed above) and the like. For example, the host organization 110 of FIG. 1, the machine 400 of FIG. 4, or the system 1211 of FIG. 12B can implement the described methodology. Some of the blocks and / or operations listed below are optional in certain embodiments. The block numbering presented is for clarity and is not intended to define the order in which the various blocks should occur.

  At block 1291, processing logic receives a tabular data set having a plurality of rows and a plurality of columns.

  At block 1292, processing logic processes the data set to generate an index that represents a probabilistic relationship between the rows and columns of the data set.

  At block 1293, processing logic stores the index in the database.

  At block 1294, processing logic exposes an application programming interface (API) for querying an index in the database.

  At block 1295, processing logic receives a request for a predictive query or a latent structure query for an index in the database.

  At block 1296, processing logic queries the database for results based on the request via the API.

  At block 1297, processing logic returns a result in response to the request. For example, a prediction record set that returns one or more predictions or other elements may be returned, such as a prediction record set describing group data, similarity data, and / or related data.

  According to another embodiment of method 1221, processing the data set includes learning a joint probability distribution across the data set to identify and explain the stochastic relationship between the elements of the data set.

  According to another embodiment of method 1221, the processing is automatically triggered in response to receiving the data set, and learning the joint probability distribution is controlled by a default setting of the configuration parameter. The

  According to another embodiment of the method 1221, learning the joint probability distribution is controlled by a specified configuration parameter, which includes a maximum duration of time to process the data set, and data The maximum number of iterations to process the set, the minimum number of iterations to process the dataset, the maximum amount of customer resources to be consumed by processing the dataset, and the maximum to be spent processing the dataset The subscriber fee, the minimum threshold predicted quality level to be achieved by processing the data set, the minimum improvement to the predicted quality measure required to continue processing, and the maximum or minimum number of indexes to be generated by the process. Of these, one or more are included.

  According to another embodiment of method 1221, processing the data set to generate an index includes iteratively learning a joint probability distribution across the data set to generate the index.

  According to another embodiment, the method 1221 further determines the predicted quality measure of the index generated by the processing of the data set periodically, and the data set when the predicted quality measure achieves a specified threshold. Terminating the process.

  According to another embodiment, the method 1221 further includes generating a query requesting a prediction from an index generated by processing the data set and terminating the processing of the data set. Executing a query against the indexed.

  According to another embodiment, the method 1221 further returns a result in response to a query that requires a prediction, a notification with a result indicating that the processing of the data set has not yet been completed, or a prediction quality. Including returning a notification with a result indicating that the scale is below a specified threshold, or both.

  According to another embodiment of the method 1221, the predicted quality measure is obtained by querying known results corresponding to values observed and present in the data set and indexes generated by processing the data set. Is determined by comparing.

  According to another embodiment of method 1221, the prediction quality measure compares ground truth data from the data set with one or more prediction results obtained by querying an index generated by processing the data set. Determined by.

  According to another embodiment of the method 1221, processing the dataset includes learning a Dirichlet process mixture model (DPMM) of the dataset, learning cross-categorization of the dataset, Learning at least one of learning an Indian buffet process model and learning a mixture or mixture model of a finite mixture model of a data set.

  According to another embodiment of method 1221, receiving the data set includes receiving the data set as a table having columns and rows, receiving the data set as a data stream, and receiving a spreadsheet document. Extracting a data set from a spreadsheet document, receiving the data set as a binary file created by the database, receiving one or more queries against the database, and receiving one or more queries against the database To receive the data set in response, capture the record set returned by one or more queries as a data set, receive the name of the table in the database, and retrieve the table from the database As a data set Receive search parameters for the specified website, responsively query the specified website for search parameters, capture the search results as a data set, and link and authentication credentials for the remote repository At least one of receiving, authenticating responsively with the remote repository, and retrieving the data set via the link.

  According to another embodiment of method 1221, each of the plurality of rows in the data set corresponds to an entity, each of the plurality of columns corresponds to a characteristic for the entity, each respective row and a plurality of columns. The intersection point with each of these forms a cell and stores the value at the intersection point.

  According to another embodiment of method 1221, each entity represents a person, place, or thing, and each characteristic represents a characteristic, feature, aspect, quantity, range, identifier, mark, characteristic, or observable fact. Each cell stores a value of a certain data type at the intersection at each respective row and each of the plurality of columns, which represents a characteristic for a row of entities that intersect the column corresponding to the characteristic. The value of every cell is null, different, or the same as any other value in any other cell.

  According to another embodiment of method 1221, each of the plurality of columns has a specified data type.

  According to another embodiment of method 1221, each data type defines a Boolean, an open set of categories, a closed set of categories, a collection of strings in a document, a collection of identifiers, and / or a collection of values. Specify the data type of the set value, quantity count, floating point number, positive floating point number, string, latitude and longitude pair, vector, positive integer, text file, Corresponding to one of the data files of the specified file type.

  According to another embodiment of the method 1221, receiving the tabular data set includes receiving a relational database object having a plurality of tables and interrelationships across the plurality of tables, the data set Processing includes generating indexes from the columns and rows in the plurality of tables while following the interrelationship between the plurality of tables.

  For example, the generation process for the analysis engine to create an index may initially divide the features / columns into multiple types, and then for each type identified, the analysis engine then categorizes the entities / rows To divide. The analysis engine utilizes a model that provides a type, and as a result of this type, each of the features provides predictive information about other features in the same type, and each category has its own as identified by the model. Includes similar entities according to the characteristics in the kind.

  PreQL structured queries provide access to the queryable index generated through its modeling by the analysis engine via specialized calls including “RELATED”, “SIMILAR”, “GROUP” and “PREDICT”. to enable.

  According to another embodiment of method 1221, the processing further includes performing a structured query language (SQL) operation on two or more of the plurality of tables to form a data set, wherein SQL The operations include at least one of a SQL transformation operation, a SQL aggregation operation, and a SQL join operation.

  According to another embodiment of the method 1221, the index is stored in the host organization's predictive database system, and the method further receives a plurality of access requests for the index stored in the host organization's predictive database system. Each access request originates from one or more client devices of a plurality of customer organizations, each customer organization being a separate and distinct remote organization, a group of organizations within the host organization, Selected from the group consisting of business partners or customer organizations that subscribe to cloud computing services provided by the host organization.

  According to another embodiment of the method 1221, the predictive database system is operably integrated with a multi-tenant database system provided by a host organization, the multi-tenant database system being operated by a plurality of distinct and distinguishable customer organizations. Each of the distinct and distinguishable customer organizations with shared hardware and software elements is located remotely from the host organization operating the predictive database system and the multi-tenant database system.

  According to another embodiment of method 1221, receiving the data set can be performed at a host organization that provides on-demand cloud-based services accessible to the remote computing device over the public Internet. Including receiving. Storing the index in the database is via the operational logic stored in the memory of the predictive database system and executed via one or more processors of the predictive database system in the predictive database system running in the host organization. Storing the index.

  According to another embodiment of the method 1221, storing the index in the database includes storing the index in the predictive database, and exposing the API for querying the index includes the predictive query language (Predictive Query Language). PreQL) including exposing the API.

  According to another embodiment of method 1221, receiving a request for a predictive query or a latent structure query for an index in the database is selected from a group of PreQL commands including PREDICT, RELATED, SIMILAR, and GROUP. Receiving a PreQL query specifying at least one command.

  According to one particular embodiment, there is a non-transitory computer readable storage medium having instructions stored thereon, said instructions having a tabular format having a plurality of rows and a plurality of columns when executed by a processor in a host organization. Receiving the data set, processing the data set to generate an index that represents a stochastic relationship between the rows and columns of the data set, storing the index in the database, and indexing in the database Publish an application programming interface (API) for querying, receiving a request for a prediction query or latent structure query for an index in the database, and querying the database for predictions based on requests via the API. And return predictions in response to requests To execute it and the operations, including the host tissue.

  The non-transitory computer readable storage medium may embody and execute any of the methodologies described herein.

  In another embodiment, processing the tabular data set is triggered automatically or manually upon receipt of the tabular data set as input at the host organization. When triggered manually, an “UPLOAD” command is issued to pass a tabular data set to the analysis engine, or the target data from which a prediction index is generated for the analysis engine for analysis. A set can be specified. In yet another embodiment, an “ANALYZE” command may be issued to instruct the analysis engine to begin analyzing the specified data set. In certain embodiments, the UPLOAD and ANALYZE command terms are used but hidden from the user and instead issued by an interface provided to the user to reduce system complexity for the user.

  The functionality of the analysis engine that generates indexes from tabular datasets is computationally intensive and is therefore well suited for distributed computing structures provided by cloud-based multi-tenant database system architectures.

  According to the described embodiment, the resulting database appears to the user like a conventional database. However, instead of selecting columns from existing rows, the user can issue a predictive query request through a structured query language. The structured language described above, which is not SQL, can be referred to as a predictive query language (“PreQL”). PreQL should not be confused with PQL, which is an abbreviation for “Program Query Language”.

  Thus, PreQL is used to query the database to predict values, events or consequences according to the model applied to the current dataset by the analysis engine and its corresponding functionality. Such PreQL queries provide the same flexibility as SQL style queries. When searching for a structure, a user can issue a PreQL query that seeks the idea of similarity that is hidden or latent in the overall data without a high degree of knowledge of what similarity can be. The user can issue a prediction query that searches for an idea of the relationship between columns without having to know the relationship in advance. A user can issue a predictive query that seeks the idea of grouping between entities in a data set without having to know or define the rules for grouping or grouping in advance. When used in a multi-tenant database system for large cloud-based databases and their data sets, the above features can change in the computing field.

  FIG. 12D depicts an exemplary architecture for implementing a predictive query interface as a cloud service in accordance with the described embodiments. Specifically, customer organizations 1205A, 1205B, and 1205C are depicted, each comprising client devices 1206A, 1206B, and 1206C, where client devices 1206A, 1206B, and 1206C send queries and responses (eg, input 1257). Capable of interfacing with host organization 1210 via public internet 1228, including receiving (e.g., predictive record set 1258). There is a request interface 1276 within the host organization 1210, which may optionally be implemented by the web server 1275. The host organization further includes a processor 1281, memory 1282, query interface 1280, analysis engine 1285, and multi-tenant database system 1230. The multi-tenant database system 1230 includes execution hardware, software, and logic 1220. The execution hardware, software, and logic 1220 include a plurality of tenants, an authenticator 1298, and one or more application servers 1265 in the multi-tenant database system 1230. A prediction result set (in response to a prediction query and / or a latent structure query (eg, requested via input 1257) executed against the prediction database 1250 is shared across the prediction database 1250. There is the ability to store the index generated by the analysis engine 1285 to facilitate returning 1258).

  According to one embodiment, host organization 1210 runs system 1231, which includes at least a processor 1281 that executes instructions stored in memory 1282 of system 1231 and a client device 1206A that operates remotely from host organization 1210. A request interface 1276 that is open to the C and accessible to the client device 1206A-C via the public Internet 1228; and a subscriber running the client device 1206A-C; Or as the above service for one or more subscribers, such as subscribers who are otherwise affiliated with various customer organizations 1205A-C to which on-demand cloud-based services are provided. Prediction data It includes a base 1250, a. According to one such embodiment, the system 1231 described above further includes an authenticator 1298 that verifies that the client device 1206A-C is associated with a subscriber and authenticates for each subscriber. Further verify the credentials. In this embodiment, the request interface will receive a request from a subscriber as input, and the system 1231 further includes one or more application servers 1265. Application server 1265 performs a query (eg, provided as input 1257 via public Internet 1228) against an index of prediction database 1250 generated from the column and row data set for the subscriber, The index represents a probabilistic relationship between the rows and columns of the data set. The request interface 1276 of the system 1231 further returns a predicted record set 1258 to the subscriber in response to the request.

  According to another embodiment, the system 1231 described above further includes a web server 1275 that implements a request interface, the web server 1275 as an input 1257 across at least a portion of the public Internet 1228 over a network and host organization. Receiving multiple access requests from one or more client devices 1206A-C in a plurality of customer organizations 1205A-C that interface with each customer organization 1205A-C, each customer organization 1205A-C having a separate and distinct remote An entity selected from the group consisting of an organization, an organizational group within the host organization, a business partner of the host organization, or a customer organization that subscribes to a cloud computing service provided by the host organization 1210. According to one such embodiment, multi-tenant database system 1230 in host organization 1210 with predictive database functionality implements a predictive database.

  According to another embodiment, the system 1231 includes an analysis engine 1285 that processes the data set and generates an index that represents a stochastic relationship between the rows and columns of the data set, and further, the prediction database 1250 generates Remembered index. According to another embodiment of system 1231, a Predictive Query Language application programming interface (PreQL API 1299) is exposed to the subscriber at request interface 1276. The PreQL API 1299 receives a PreQL query (eg, as input 1257) having at least one command selected from a group of PreQL commands including PREDICT, RELATED, SIMILAR, and GROUP, after which the PreQL API 1299 returns to the prediction database. To execute a PreQL query and return a predicted record set 1258.

  Thus, the use of a PreQL structure query allows programmatic queries to the indexes generated and stored in the prediction database in a manner similar to programmers making SQL queries to a relational database. Instead of the “SELECT” command term, various predictive PreQL-based command terms are used instead, such as “PREDICT” or “SIMILAR” or “RELATED” or “GROUP” statements. For example, an exemplary PreQL statement can be read as follows: “PREDICT IS_WON, DOLLAR_AMOUNT FROM OPPORTUNITY WHERE STAGE =‘ QUATTE ’”. Thus, in this example, “QUIOTE” is a fixed column, “FROM” is the data set for which the opportunity is to be predicted, the “PREDICT” command term is a call to the appropriate function, and “ “IS_WON” is a value to be predicted. That is, this functionality is to predict whether a given opportunity will or will not win, where “IS_WON” is due to, for example, pending or speculative opportunities, etc. You have completed the data for some rows, but may be missing for some rows. “DOLLAR_AMOUNT” is a fixed value.

  In a particular embodiment, the above query is performed via a specialized GUI interface, which is the underlying PreQL structure query that the user actually makes against the analysis engine core. Without needing to write or even be aware of it, it receives input from the user via the GUI interface and builds, calls and returns data via the PREDICT functionality for the user.

  Another exemplary PreQL statement can be read as follows: SELECT ID; FROM Opportunity WHERE SIMILAR / Stage / 001> 0.8 ORDER BY SIMILAR / Stage LIMIT 100. In this example, a specific ID is retrieved from the “Opportunity” table in the database, and then the SIMILAR command term is used to determine whether an entity or row similar to the specified ID is equal to “0.8” or Find and identify such entities or rows as long as they have a higher confidence quality indicator. Eventually, the outputs are ordered by Stage and are allowed to produce up to 100 total record outputs. This example uses a mix of both SQL and PreQL in the query (eg, the “SELECT” command term is a SQL command and the “SIMILAR” command term is PreQL specific).

  FIG. 12E is a flow diagram illustrating a method for implementing a predictive query interface as a cloud service in accordance with the disclosed embodiments. The method 1222 may be performed by processing logic that includes hardware (e.g., circuitry, dedicated) according to a system, apparatus, and method for implementing a predictive query as a cloud service as described herein. Logic, programmable logic, microcode, etc.), software (eg, send, send, receive, execute, generate, calculate, store, publish, authenticate, query, process, reply, etc. on the processing device Instructions executed in the For example, the host organization 110 of FIG. 1, the machine 400 of FIG. 4, or the system 1231 of FIG. 12D can implement the described methodology. Some of the blocks and / or operations listed below are optional in certain embodiments. The block numbering presented is for clarity and is not intended to define the order in which the various blocks should occur.

  At block 1270, processing logic exposes an interface to client devices operating remotely from the host organization, which is accessible to the client device over the public Internet.

  At block 1271, processing logic executes the prediction database at the host organization as an on-demand cloud-based service for one or more subscribers.

  At block 1272, processing logic authenticates one of the client devices by verifying that the client device is associated with one of the subscribers and is further based on authentication credentials for each subscriber. To do.

  At block 1273, processing logic receives a request via an interface from an authenticated subscriber.

  At block 1274, processing logic performs a predictive or latent structure query against the predictive database index generated from the column and row data sets for the authenticated subscriber. The index represents a probabilistic relationship between the rows and columns of the data set.

  At block 1279, processing logic returns a predicted record set to the authenticated subscriber in response to the request.

  According to another embodiment of method 1222, executing the query includes executing a predictive query language (PreQL) query against the prediction database.

  According to another embodiment of the method 1222, executing the PreQL query queries the prediction database by specifying at least one command selected from a group of PreQL commands including PREDICT, RELATED, SIMILAR, and GROUP. including.

  According to another embodiment of the method 1222, receiving a request from an authenticated subscriber via a predictive query language (PreQL) API that is exposed directly to the authenticated subscriber via the interface. Receiving a PreQL query.

  According to another embodiment of the method 1222, receiving the request presents a web form to the authenticated subscriber and receives input from the authenticated subscriber via the web form; Predictive query by generating a PreQL query for the authenticated subscriber based on the input and specifying at least one command selected from a group of PreQL commands including PREDICT, RELATED, SIMILAR and GROUP Querying the prediction database via a language (PreQL) API.

  According to another embodiment of the method 1222, an authenticated subscriber accesses an on-demand cloud-based service via a web browser provided by a third party different from the host organization, and the authenticated subscriber Submits a request to the host organization and receives a predictive record set from the host organization without installing any software from the host organization on the client device.

  According to another embodiment, the method 1222 is further authenticated for the purpose of receiving a data set from the authenticated subscriber and generating an index prior to receiving a request from the authenticated subscriber. Each of the indices represents a stochastic relationship between the rows and columns of the data set.

  According to another embodiment of method 1222, receiving the data set includes receiving the data set as a table having columns and rows, receiving the data set as a data stream, and receiving a spreadsheet document. Extracting a data set from a spreadsheet document, receiving the data set as a binary file created by the database, receiving one or more queries against the database, and receiving one or more queries against the database To receive the data set in response, capture the record set returned by one or more queries as a data set, receive the name of the table in the database, and retrieve the table from the database As a data set Receive search parameters for the specified website, responsively query the specified website for search parameters, capture the search results as a data set, and link and authentication credentials for the remote repository At least one of receiving, authenticating responsively with the remote repository, and retrieving the data set via the link.

  According to another embodiment of the method 1222, processing the data set for the authenticated subscriber identifies joint probabilities across the data set to identify and explain a probabilistic relationship between elements of the data set. Including learning the distribution.

  According to another embodiment of method 1222, the processing is automatically triggered in response to receiving the data set, and learning the joint probability distribution is controlled by default settings of the configuration parameters. The According to another embodiment of the method 1221, learning the joint probability distribution is controlled by a specified configuration parameter, which includes a maximum duration of time to process the data set, and data The maximum number of iterations to process the set, the minimum number of iterations to process the dataset, the maximum amount of customer resources to be consumed by processing the dataset, and the maximum to be spent processing the dataset Subscriber fee, minimum threshold reliability quality level to be achieved by processing the data set, minimum improvement to the reliability quality measure required to continue processing, and maximum or minimum index to be generated by the process One or more of the numbers are included.

  According to another embodiment of method 1222, processing the data set includes iteratively learning a joint probability distribution across the data set to generate an index, and the method is further generated by processing the data set. Periodically determining a predicted quality measure for the index to be processed and terminating processing of the data set when the reliability quality measure achieves a specified threshold.

  According to another embodiment, the method 1222 further includes a notification with a predictive record set indicating that processing of the stored data set has not yet been completed, or the reliability quality measure is below a specified threshold. Including a notification with a predicted record set indicating or both.

  According to another embodiment of the method 1222, the reliability quality measure is obtained by querying known results corresponding to known and non-null values in the data set and an index generated by processing the data set. Determined by comparing with the predicted record set.

  According to another embodiment of the method 1222, the host organization includes a plurality of application servers, and the processing further includes distributing the generation of the index and storing the index in the plurality of application servers. Querying the index of the prediction database includes querying a plurality of generated indexes among a plurality of application servers that have distributed and stored the index, and generating a generated index. Aggregating the results returned by querying a plurality of them.

  According to another embodiment of the method 1222, querying the generated index in parallel produces different results from different versions of the index on multiple of the stored application servers.

  According to another embodiment, the method 1222 further includes aggregating various results and one prediction in response to the latent structure query being executed or one in response to the prediction query being executed. Returning a prediction.

  According to another embodiment of the method 1222, a higher number of generated indexes corresponds to improved prediction accuracy, and a higher number of application servers that distribute and store the indexes may Responds to improved response time.

  According to another embodiment, the method 1222 further includes receiving a designated data source from the authenticated subscriber and periodically updating the index based on the designated data source. .

  According to another embodiment of the method 1222, periodically updating the index initiates a polling mechanism that checks for changes in the specified data source and when detected for use in updating the index. Retrieving the change, receiving a push notification from the specified data source indicating that a change in the specified data source has occurred, and accepting the change for use in updating the index; Including at least one of these, the index update occurs without requiring an active authenticated session for the subscriber.

  According to another embodiment, the method 1222 further comprises performing a structured query language (SQL) operation on two or more tables in the host organization accessible to authenticated subscribers, comprising: The operations include at least one of a SQL transformation operation, a SQL aggregation operation, and a SQL join operation, capturing the output of the SQL operation as a row and column data set, and probabilities in the rows and columns of the data set Processing the data set to generate an index representative of the physical relationship.

  According to another embodiment of the method 1222, the authenticated subscriber specifies two or more tables as input, and the host organization generates a query that performs the SQL operation, for the authenticated subscriber. Start processing automatically on the dataset.

  According to another embodiment, the method 1222 further learns a Dirichlet process mixture model (DPMM) of the data set, learns cross categorization of the data set, and learns an Indian buffet process model of the data set. Generating an index representing a stochastic relationship in the rows and columns of the data set by learning at least one of learning and learning a mixture model or mixture of a finite mixture model of the data set Including.

  According to another embodiment of method 1222, each of the plurality of rows in the data set corresponds to an entity, each of the plurality of columns corresponds to a characteristic for the entity, each respective row and a plurality of columns. The intersection point with each of these forms a cell and stores the value at the intersection point.

  According to another embodiment of the method 1222, each entity represents a person, place, or thing, and each characteristic represents a characteristic, feature, aspect, quantity, range, identifier, mark, characteristic, or observable fact. Each cell stores a value of a certain data type at the intersection at each respective row and each of the plurality of columns, which represents a characteristic for a row of entities that intersect the column corresponding to the characteristic. The pre-selectable value for every cell is null, different, or the same as any other value in any other cell.

  According to another embodiment, there is a non-transitory computer readable storage medium having instructions stored thereon that are executed by a processor at the host organization for a client device operating remotely from the host organization. The interface is accessible to client devices over the public Internet and is hosted as an on-demand cloud-based service for one or more subscribers By running a predictive database in the organization and verifying one of the client devices that the client device is associated with one of the subscribers and is further based on authentication credentials for each subscriber Authenticating and authenticated subscribers Receiving a request via an interface and executing a query against a predictive database index generated from column and row datasets for an authenticated subscriber, the index being Representing a probabilistic relationship between the rows and columns of the data set, and returning a predictive record set to the authenticated subscriber in response to the request.

  FIG. 13A illustrates the use of a RELATED command term according to the described embodiment. Once the analysis engine generates an index from the tabular data set provided as described above, specialized queries are made feasible. For example, the user can ask the prediction database “for a given column, which other columns are predictively related to it?”. In the language of the queryable index, this translates into “How often does each other column appear in the same view?” As depicted in element 1302. In terms of cross-categorization, the analysis engine tabulates how often each of the other columns appears in the same view as the input column, thus revealing what is important and what is not important To do. All that the user needs to provide as input is the column ID 1301 in the use of the RELATED command term.

  Further predictive functionality provided by the RELATED command term allows the user to query for columns associated with a specified column according to a probabilistic model. For example, given a table with columns or variables, the analysis engine divides the columns or variables into groups. There are several ways to divide the columns or variables for distribution. For example, take height as an example. Given a height column in the RELATED command term API call, the user asks "How confident can I be with respect to the probability of the relationship that exists between the specified height column and all other columns?" You can inquire. The RELATED command term will then return a confidence measure for any other column not specified in the data set for the specified height column. Thus, for example, the RELATED functionality may return “weight = 1.0” for its confidence index for the height column, which indicates that the analysis engine may determine that between the weight and height, according to the data set. It means that you are very confident in your relationship.

  While the above results are somewhat intuitive and expected, other results are less intuitive and therefore may provide interesting results for searching and further pursuit. Continuing with the “height” example for the column specified for the RELATED command term API call, the analysis engine may return “age = 0.8”, which means that for the data set being analyzed This means that the analysis engine has determined that age is highly correlated, but not as completely confident as weight. The lower confidence index score may be due to noise data that excludes absolute positive results, for example.

  Perhaps the additional returned for the specified “height” column is “hair color = 0.1”, which, according to the data set used, is between the height of the person and its hair color. It means that there is no real connection. Thus, the RELATED functionality allows the user to query what is important for a given column, such as a height column, and how this functionality relates to all the columns specified. Returns the above sequence with a score based on its probability. Although it can be intuitive for humans to understand that height and weight are related, the analysis engine systematically generates the above results without human input, and more importantly, the analysis engine It can be applied to data sets whose relationships are not intuitive or easily understood by the person viewing the data. This is especially true for larger data sets where the relationship exists but the relationship is not defined by the data structure itself. The analysis engine learns the underlying latent structures and relationships, which is hidden even for the general user who wants to explore his data in ways that were simply not feasible historically. Help clarify the structure.

  FIG. 13B depicts an example architecture in accordance with the described embodiments. Specifically, customer organizations 1305A, 1305B, and 1305C are depicted, each comprising client devices 1306A, 1306B, and 1306C, including client devices 1306A, 1306B, and 1306C sending requests and receiving responses. , Capable of interfacing with host organization 1310 via network 1325. There is a request interface 1376 within the host organization 1310, which may optionally be implemented by the web server 1375. The host organization further includes a processor 1381, memory 1382, query interface 1380, analysis engine 1385, and multi-tenant database system 1330. There is execution hardware, software, and logic 1320 in the multi-tenant database system 1330, and the execution hardware, software, and logic 1320 are shared across multiple tenants of the multi-tenant database system 1330, the authenticator 1398, and the prediction database 1350, The prediction database 1350 is capable of storing an index generated by the analysis engine to facilitate returning a prediction record set in response to a query executed against the prediction database 1350.

  According to one embodiment, the host organization 1310 runs a system 1311 having at least one processor 1381 and memory 1382. The system 1311 is enabled to generate an index from the column and row data set via the analysis engine 1385, where the index represents a stochastic relationship between the rows and columns of the data set. The system 1311 further includes a prediction database 1350 that stores an index and a request interface 1376 that exposes the prediction database to, for example, a user or client device 1306A-C, with a RELATED command term for the prediction database. And a query 1353 specifying a specified column as a parameter of the RELATED command term, and a prediction by passing the specified column using the RELATED command term to generate a request interface 1376 and a predicted record set 1354 A query interface 1380 that queries the database 1350, and the request interface 1376 further returns a predicted record set 1354 in response to the query. In one such embodiment, the predicted record set 1354 includes a plurality of elements 1399 therein, each of the returned elements having a column identifier and a confidence index for the specified column passed in the RELATED command term. Including. In one such embodiment, the confidence measure indicates whether a latent relationship exists between the specified column passed in the RELATED command and the column identifier returned for each element 1399.

  According to one embodiment, the prediction database 1350 is implemented as an on-demand cloud-based service at the host organization 1310 for one or more subscribers. In one such embodiment, the system further includes an authenticator 1398 that verifies that the client device 1306A-C is associated with a subscriber and further verifies the authentication credentials for each subscriber.

  According to one embodiment, the request interface 1376 exposes the Predictive Query Language application programming interface (PreQL API) directly to the authenticated user, which is accessed via the public internet for the authenticated user. Is possible. For example, network 1325 may operate to link host organization 1310 to subscribers over the public Internet.

  According to one embodiment, the system 1311 described above includes a web server 1375 that implements a request interface 1376, which, as an input, includes a plurality of customer organizations that interface with a host organization over a network. A plurality of access requests are received from one or more client devices 1306A-C in 1305A-C. In one such embodiment, a multi-tenant database system 1330 with predictive database functionality implements the predictive database 1350.

  FIG. 13C is a flow diagram illustrating a method 1321 according to a disclosed embodiment. Method 1321 may be performed by processing logic that includes hardware according to a system, apparatus, and method that implements a RELATED command with a predictive query interface as described herein. Circuit, dedicated logic, programmable logic, microcode, etc.), software (eg, send, send, receive, execute, generate, calculate, store, publish, query, process, etc. on the processing device to perform various operations Instructions to be executed) and the like. For example, the host organization 110 of FIG. 1, the machine 400 of FIG. 4, or the system 1311 of FIG. 13B can implement the described methodology. Some of the blocks and / or operations listed below are optional in certain embodiments. The block numbering presented is for clarity and is not intended to define the order in which the various blocks should occur.

  At block 1391, processing logic generates an index from the column and row data sets. The index represents a probabilistic relationship between the rows and columns of the data set.

  At block 1392, processing logic stores the index in the host organization's database.

  At block 1393, processing logic publishes the host organization's database via the request interface.

  At block 1394, processing logic receives a query in the request interface that specifies a RELATED command term and a column specified as a parameter of the RELATED command term for the database.

  At block 1395, processing logic queries the database passing the specified column using the RELATED command term to generate a predicted record set.

  At block 1396, processing logic returns a predicted record set in response to the query, the predicted record set having a plurality of elements therein. In one such embodiment, each returned element includes a column identifier and a confidence index for the designated column passed in the RELATED command term, and the confidence metric is designated by the RELATED command. Indicates whether a latent relationship exists between the column and the column identifier returned for each element.

  According to another embodiment, the method 1321 further includes passing a minimum confidence threshold in a RELATED command term. In one such embodiment, returning the predicted record set includes returning only elements of the predicted record set that have a confidence measure that exceeds a minimum confidence threshold.

  According to another embodiment, the method 1321 further includes passing a limited record set with a RELATED command term to limit the quantity of elements returned in the predicted record set.

  According to another embodiment of the method 1321, the elements of the predictive record set are returned in descending order according to a confidence index for each of the predictive record set elements, or for each of the predictive record set elements. Returned in ascending order according to the confidence index.

  According to another embodiment of the method 1321, the predictively related column included in each element returned in the predictive record set is specified by the predictive related column passed in the RELATED command term. Further based on the fraction of the number of occurrences in the same column grouping as the previous column.

  According to another embodiment of the method 1321, a predicted record set having a plurality of elements therein, each returned element includes all of the columns and the corresponding predicted value for any one of the columns. The method further includes, for each corresponding predicted value, a maximum possible confidence in each predicted value from 0 indicating a minimum possible confidence level in the respective predicted value. Including returning a confidence index up to 1 indicating the degree level.

  According to another embodiment, the method 1321 further includes extracting one or more of the predictively related columns from a predictive record set generated in response to querying the database using the RELATED command term to the predictor. Identifying one or more identified among the predictively related columns into a second query specifying a PREDICT command term or a GROUP command term. Limiting the second predicted record set returned from the second query.

  According to another embodiment of the method 1321, querying the database using the RELATED command term is between the specified column passed in the RELATED command term and the column identifier returned for each element of the predicted record set. Including the database estimating the mutual information.

  According to another embodiment of the method 1321, publishing a host organization database includes publishing a Predictive Query Language Application Programming Interface (PreQL API) directly to an authenticated user, the PreQL API being Authenticated users can access via the public internet.

  According to another embodiment of the method 1321, querying the database using a RELATED command term includes passing a PreQL query to the database, the PreQL query including a RELATED command term as a required term and an optional A FROM term that specifies one or more tables, data sets, data sources, and / or indexes to be queried when this optional FROM term is specified, and is queried when an optional FROM term is not specified A FROM term in which default values are used for one or more tables, data sets, data sources and / or indexes, and a TARGET term specifying a column to be passed in the RELATED command term; With the query syntax. For example, if no FROM term is specified, the system may determine the source based on the user's context. For example, a user may have only one data source or be associated with a particular organization that has a primary data source, or assuming the last evaluated or most frequently accessed data source Alternatively, defaults may be preconfigured as user preferences.

  According to another embodiment of the method 1321, the query syntax of the PreQL query is further an optional CONFIDENCE term that, when provided, specifies the minimum acceptable confidence measure to be returned in the predicted record set. A CONFIDENCE term and an optional COUNT term that, when provided, specifies the maximum quantity of elements to be returned in the predicted record set, and is provided with a COUNT term and an optional ORDER BY term One of the ORDER BY terms that specifies whether the elements of the prediction record should be returned in ascending or descending order according to a confidence measure for each of the elements returned in the prediction record set Provide multiple.

  According to another embodiment of the method 1321, querying the database using a RELATED command term includes passing a JavaScript Object Notation (JSON) structured query to the database, wherein the JSON structured query is: A RELATED command term as a required term and any one or more tables, data sets, data sources and / or indexes to be queried, or one or more tables, data sets to be queried when not specified, An optional specification of the default value of the data source and / or index, the column passed in the RELATED command term, and the minimum acceptable confidence to be returned in the predicted recordset according to the confidence index; The elements of the forecast record should be returned in descending or ascending order, depending on an optional specification of the maximum quantity of elements to be returned in the forecast record set and the confidence index for each of the elements returned in the forecast record set It has an optional specification and a query syntax.

  According to another embodiment of the method 1321, publishing the host organization database includes publishing a web form directly to an authenticated user, the web form being public to the authenticated user. Accessible via the Internet. The host organization generates a latent structure query for submission to the database based on the input from the web form. Querying the database using the RELATED command term includes querying the database using a latent structure query via the Predictive Query Language Application Programming Interface (PreQL API) within the host organization, where the PreQL API is the authenticated user Published indirectly through a web form.

  According to another embodiment of method 1321, querying a database using a RELATED command term includes executing a Predictive Query Language (PreQL) structured query against the database for the RELATED command term. The method further includes executing one or more additional PreQL structured queries against the database, each of the one or more additional PreQL structured queries being PREDICT, RELATED, SIMILAR, and GROUP. Specifies at least one command selected from a group of PreQL commands including.

  According to another embodiment, the method 1321 further receives a data set from an authenticated subscriber and then receives a query against the database from the authenticated subscriber and generates an index. Processing the data set for the authenticated subscriber.

  According to another embodiment of method 1321, each of the plurality of rows in the data set corresponds to an entity, each of the plurality of columns corresponds to a characteristic for the entity, each respective row and a plurality of columns. The intersection point with each of these forms a cell and stores the value at the intersection point.

  In accordance with certain embodiments, there is a non-transitory computer readable storage medium having instructions stored thereon, which when executed by a processor in a host organization, generate an index from a column and row data set. The index represents a stochastic relationship between the rows and columns of the dataset, storing the index in the host organization database, and exposing the host organization database via the request interface; In the request interface, using a RELATED command term to receive a query to a database specifying a RELATED command term and a column specified as a parameter for the RELATED command term, and to generate a predicted record set The specified column Querying the database and returning a predicted record set in response to the query, the predicted record set having a plurality of elements therein, each returned element being passed in a RELATED command term Includes a column identifier for the specified column and a confidence index, which indicates whether a latent relationship exists between the specified column passed in the RELATED command and the column identifier returned for each element. Instructing the host organization to perform operations including

  FIG. 14A illustrates the use of a GROUP command term according to the described embodiment. Using the GROUP command term, the user can ask "Which rows are together?" These features can be conceptualized as clustering, except that there are two or more ways to cluster the dataset. Consider the mammal example used above in the form that column ID 1401 is provided as input. In response to the above query, a prediction data set will be returned as output 1402 with groups against the provided columns. More specifically, the output 1402 will indicate which rows most frequently appear together as a group in the same category in the view containing the input column.

  Sometimes rows tend to group on noise elements in a dataset when the analysis engine applies its modeling to generate an index, but these noise elements sometimes group things that are not really important Bring. Using the GROUP command term functionality, the user knows that each column will appear in exactly one of the groups as a view, so the analysis engine will use the user-specified column. Allows identification of a specific “view”. Thus, the GROUP functionality performs a row-centric operation similar to the SIMILAR functionality. However, in contrast to the SIMILAR API call in which a user specifies a row and receives a list of other rows and corresponding scores based on their similar probabilities in return, the GROUP functionality It does not need to be specified or fixed by the user. Instead, when making a call specifying a GROUP command term, only the column needs to be provided by the user.

  Invoking the GROUP functionality with a specified or fixed column causes this functionality to return a grouping of ROWS that may be related or correlated in some way based on the modeling of the analysis engine.

  FIG. 14B depicts an example architecture in accordance with the described embodiments. Specifically, customer organizations 1405A, 1405B, and 1405C are depicted, each comprising client devices 1406A, 1406B, and 1406C, including client devices 1406A, 1406B, and 1406C sending requests and receiving responses. , Capable of interfacing with host organization 1410 via network 1425. Within the host organization 1410 is a request interface 1476, which may optionally be implemented by the web server 1475. The host organization further includes a processor 1481, memory 1482, query interface 1480, analysis engine 1485, and multi-tenant database system 1430. There is execution hardware, software, and logic 1420 in the multi-tenant database system 1430, and the execution hardware, software, and logic 1420 are shared across multiple tenants of the multi-tenant database system 1430, the authenticator 1498, and the prediction database 1450, The prediction database 1450 is capable of storing an index generated by the analysis engine to facilitate returning a prediction record set in response to a query executed against the prediction database 1450 by a query interface.

  According to one embodiment, the host organization 1410 runs a system 1411 having at least one processor 1481 and memory 1482. System 1411 includes an analysis engine 1485 that generates an index from a column and row data set, where the index represents a stochastic relationship between the rows and columns of the data set. The system 1411 further includes a prediction database 1450 that stores the index and a request interface 1476 that exposes the prediction database to, for example, a user or client device 1406A-C, the GROUP command term for the prediction database. And a query 1453 specifying a column specified as a parameter of the GROUP command term, a request interface 1476, and a prediction by passing the column specified using the GROUP command term so as to generate a prediction record set 1454 A query interface 1480 that queries the database 1450, and the request interface 1476 further returns a predicted record set 1454 in response to the query 1453. The predicted record set includes a plurality of groups 1499 specified therein, and each returned group 1499 of the predicted record set includes a group of one or more rows of the data set. For example, in the depicted prediction record set 1454, there are four groups A 1456, Group B 1457, Group C 1458 and Group D 1459 returned, each of which contains a set of {rows}.

  FIG. 14C is a flow diagram illustrating a method in accordance with the disclosed embodiments.

  Method 1421 may be performed by processing logic that includes hardware according to a system, apparatus, and method for implementing a GROUP command with a predictive query interface as described herein (eg, Circuit, dedicated logic, programmable logic, microcode, etc.), software (eg, send, send, receive, execute, generate, calculate, store, publish, query, process, etc. on the processing device to perform various operations Instructions to be executed) and the like. For example, the host organization 110 of FIG. 1, the machine 400 of FIG. 4, or the system 1411 of FIG. 14B can implement the described methodology. Some of the blocks and / or operations listed below are optional in certain embodiments. The block numbering presented is for clarity and is not intended to define the order in which the various blocks should occur.

  At block 1491, processing logic generates an index from the column and row data sets. The index represents a probabilistic relationship between the rows and columns of the data set.

  At block 1492, processing logic stores the index in the host organization's database.

  At block 1493, processing logic publishes the host organization's database via the request interface.

  At block 1494, processing logic receives a query specifying a GROUP command term and a column specified as a parameter of the GROUP command term for the database at the request interface.

  At block 1495, processing logic queries the database passing the specified column using the GROUP command term to generate a predicted record set.

  At block 1496, processing logic returns a predicted record set in response to the query. The predicted record set has a plurality of groups specified therein, and each of the returned groups of the predicted record set includes a group of one or more rows of the data set.

  According to another embodiment of the method 1421, all of the rows of the data set are returned in the predicted record set without any overlap where any single row is assigned to two or more of the groups. It is delimited by assigning every row of the data set to exactly one of the groups.

  According to another embodiment of method 1421, the rows of the data set are at most one of the plurality of groups without any overlap where any single row is assigned to two or more of the plurality of groups. It is segmented by assigning rows to the dataset. This segmentation results in one or more rows of the data set remaining unassigned to any of the groups, for the corresponding one or more rows that remain unassigned. This is because the reliability index is in a range below the minimum threshold.

  According to another embodiment of the method 1421, the confidence measure returned in each of the one or more rows specified in each of the plurality of groups returned in the predicted record set is the group in which the respective row is specified. The minimum value 0 indicating the minimum possible reliability in the prediction of belonging to the range from 1 to the maximum value 1 indicating the maximum possible reliability in the prediction that each row belongs to the specified group.

  According to another embodiment of the method 1421, the columns passed in the GROUP command term are evaluated for the similarity of one or more rows of each specified group to any other row in the same group. Provides the context of the latent structure.

  According to another embodiment of the method 1421, a predicted record set having a plurality of groups specified includes a list of row identifiers from the data set or index, and a corresponding confidence measure for each of the specified row identifiers. including.

  According to another embodiment of the method 1421, each row corresponds to a registered voter, and the grouping specified by the prediction record is such that each voting block has a common campaign message, a common campaign issue, and / or a common Define a voting block that can be naturally targeted in a state that is expected to react similarly to the campaign ad.

  According to another embodiment of the method 1421, each row corresponds to an economic market participant, and the grouping specified by the forecast record is a common advertising campaign that the economic market participants of each advertising group are directed to themselves. Define ad groups that can naturally be targeted in a state where they are expected to react similarly.

  According to another embodiment, the method 1421 further includes indicating the most representative row in each of the respective groups returned in the predicted record set, the most representative row for each of the returned groups. Corresponds to the actual row of the dataset.

  According to another embodiment, the method 1421 further includes indicating the most stereotypical row in each of the respective groups returned in the prediction record set, the most stereotype row being as a row of the data set. Does not exist and is synthesizing data based on the actual rows in the data set for the specified group to which the most stereotypical rows correspond.

  According to another embodiment, the method 1421 further includes passing a minimum confidence threshold in a GROUP command term, wherein returning a predicted record set is for a predicted record set having a confidence index that exceeds the minimum confidence threshold. Includes returning only the rows in the middle group.

  According to another embodiment of the method 1421, publishing a host organization database includes publishing a Predictive Query Language Application Programming Interface (PreQL API) directly to an authenticated user, the PreQL API being Authenticated users can access via the public internet.

  According to another embodiment of the method 1421, querying the database using the GROUP command term includes passing a PreQL query to the database, the PreQL query including the GROUP command term as the required term and the required term. A COLUMN term that specifies the sequence to be passed in the GROUP command term, a COLUMN term, and an optional FROM term, one or more to be queried when this optional FROM term is specified Specify one table, data set, data source, and / or index, and default for one or more tables, data sets, data sources, and / or indexes to be queried when an optional FROM term is not specified. DOO value is used, it comprises a FROM terms, the query syntax.

  According to another embodiment of the method 1421, the query syntax of the PreQL query is further an optional CONFIDENCE term, and when provided, the minimum acceptable confidence for the row to be returned in the group of predicted recordsets Provides a CONFIDENCE term that specifies a degree indicator.

  According to another embodiment of the method 1421, querying the database using the GROUP command term includes passing a JavaScript Object Notation (JSON) structured query to the database, wherein the JSON structured query is: GROUP command terms as required terms and any one or more tables, data sets, data sources and / or indexes to be queried, or one or more tables, data sets to be queried when not specified, Minimum acceptability for groups of rows returned in the predicted recordset according to the default value of the data source and / or index, the column passed in the GROUP command term, and the confidence index corresponding to each of the rows It has a query syntax of optional specification of reliability.

  According to another embodiment of the method 1421, publishing the host organization database includes publishing a web form directly to the authenticated user, the web form being public to the authenticated user. Accessible via the Internet. The host organization generates a latent structure query for submission to the database based on the input from the web form. Querying the database using the GROUP command term includes querying the database using a latent structure query via the Predictive Query Language Application Programming Interface (PreQL API) within the host organization, where the PreQL API is used by authenticated users. Published indirectly through a web form.

  According to another embodiment of method 1421, querying a database using a GROUP command term includes executing a Predictive Query Language (PreQL) structured query against the database for the GROUP command term. , The method further includes executing one or more additional PreQL structured queries against the database, wherein each of the one or more additional PreQL structured queries is PREDICT, GROUP, GROUP and GROUP. Specifies at least one command selected from a group of PreQL commands including.

  According to another embodiment, the method 1421 further receives a data set from an authenticated subscriber and then receives a query to the database from the authenticated subscriber and generates an index. Processing the data set for the authenticated subscriber.

  According to another embodiment of method 1421, each of the plurality of rows in the data set corresponds to an entity, each of the plurality of columns corresponds to a characteristic for the entity, each respective row and a plurality of columns. The intersection point with each of these forms a cell and stores the value at the intersection point.

  According to another embodiment, there is a non-transitory computer readable storage medium having instructions stored thereon that, when executed by a processor in a host organization, generate an index from a column and row data set. The index represents a stochastic relationship between the rows and columns of the dataset, stores the index in the host organization database, and exposes the host organization database via the request interface. In the request interface, a GROUP command term is received so as to receive a query specifying a GROUP command term and a column specified as a parameter of the GROUP command term for the database, and to generate a predicted record set. Pass the specified column using Querying the base and returning a predicted record set in response to the query, wherein the predicted record set has a plurality of groups specified therein, each of the returned groups of the predicted record set being , Including a group of one or more rows of the data set;

  FIG. 15A illustrates the use of the SIMILAR command term according to the described embodiment. Using the SIMILAR command term, the user can ask "which row is most similar to a given row?" Rows may be similar in one context but dissimilar in another context. For example, killer whales and blue whales are quite similar, but very different. Input 1501 specifies both the row ID and column ID to be passed in the SIMILAR command term. The input column (or column ID) provides the context of the latent structure, in which case the specified row is evaluated for similarity against similar rows returned by elements of the predicted record set. In response to the above query, the prediction data set will be returned as an output 1502 that identifies how often each row appears in the same category as the input row in the view containing the input columns. .

  The SIMILAR command term functionality accepts an entity (eg, row or row ID) and then returns which other row is most similar to the specified row. Similar to the example of the RELATED command term, the SIMILAR command term functionality returns the probability that the specified row and any respective returned row actually present similarity. For example, rather than specifying a column, the user can specify “Fred” as a row or entity in the data set. The user then queries through the SIMILAR command term functionality “Which rows will be scored based on the most likely Fred probability?”. The API call will then return all rows from the data set with the corresponding confidence score, or only those rows that are above or below the specified threshold. For example, perhaps the line above 0.8 is the most interesting, the line below 0.2 is the most interesting, or both are interesting, or the range is interesting. Nevertheless, the SIMILAR command term functionality scores every row in the data set according to its probabilistic similarity to the specified row, and then given the constraints of the user or the GUI to enforce. The ability to return a row and its respective score according to its constraints.

  Since the analysis engine uses its own modeling to determine the above relationships, there are two or more ways to assess these studies. Thus, in addition to accepting that an entity (eg, a row or row ID) is evaluated for similarity, the user can further determine how the row similarity should be evaluated. Provides which API call of the SIMILAR command term which column (or column ID) is to be used by the analysis engine. Thus, API calls that specify the SIMILAR command term require that both rows and columns be fixed. Thus, disambiguation information is provided to the analysis engine into which the index is placed by providing, specifying or fixing column variables. Otherwise, the analysis engine will score the returned rows because it will lack focus or entry points to determine how much the user presenting the query cares about the information for which similarity is sought. There are too many possible ways to do this.

  FIG. 15B depicts an example architecture in accordance with the described embodiments. Specifically, customer organizations 1505A, 1505B and 1505C are depicted, each comprising client devices 1506A, 1506B and 1506C, including client devices 1506A, 1506B and 1506C sending requests and receiving responses. Have the ability to interface with host organization 1510 via network 1525. There is a request interface 1576 within the host organization 1510, which may optionally be implemented by the web server 1575. The host organization further includes a processor 1581, memory 1582, query interface 1580, analysis engine 1585, and multi-tenant database system 1530. There is execution hardware, software and logic 1520 in the multi-tenant database system 1530, and the execution hardware, software and logic 1520 is shared across multiple tenants of the multi-tenant database system 1530, the authenticator 1598, and the prediction database 1550, The prediction database 1550 is capable of storing an index generated by the analysis engine to facilitate returning a prediction record set in response to a query executed against the prediction database 1550.

  According to one embodiment, the host organization 1510 runs a system 1511 having at least one processor 1581 and memory 1582. System 1511 includes an analysis engine 1585 that generates an index from a column and row data set, where the index represents a stochastic relationship between the rows and columns of the data set. The system 1511 further includes a prediction database 1550 that stores an index and a request interface 1576 that exposes the prediction database to, for example, a user or client device 1506A-C, the SIMILAR command term for the prediction database. And a request interface 1576 that receives a query 1553 that specifies a row specified as a parameter of the SIMILAR command term and a column specified as a parameter of the SIMILAR command term. In the above system, the query interface 1580 queries the prediction database 1550 using the SIMILAR command term, passing the specified row and the specified column, to generate a prediction record set 1554. For example, a SIMILAR command term and its operands (column ID and row ID) can be executed against the prediction database 1550.

  In the system 1511 described above, the request interface 1576 further returns a predicted record set 1554 in response to the query 1553, the predicted record set 1554 includes a plurality of elements 1599, each of the returned elements of the predicted record set 1554 is ( i) a row identifier corresponding to a row of the data set evaluated to be similar according to the latent structure, based on the specified column, for the specified row passed in the SIMILAR command term; (ii) It includes a confidence measure that indicates the likelihood of a latent relationship between the specified row passed in the SIMILAR command and the row identifier returned for each element 1599.

  FIG. 15C is a flow diagram illustrating one method according to a disclosed embodiment. Method 1521 may be performed by processing logic that includes hardware according to a system, apparatus, and method that implements a SIMILAR command with a predictive query interface as described herein. Circuit, dedicated logic, programmable logic, microcode, etc.), software (eg, send, send, receive, execute, generate, calculate, store, publish, query, process, etc. on the processing device to perform various operations Instructions to be executed) and the like. For example, the host organization 110 of FIG. 1, the machine 400 of FIG. 4, or the system 1511 of FIG. 15B can implement the described methodology. Some of the blocks and / or operations listed below are optional in certain embodiments. The block numbering presented is for clarity and is not intended to define the order in which the various blocks should occur.

  At block 1591, processing logic generates an index from the column and row data sets. The index represents a probabilistic relationship between the rows and columns of the data set.

  At block 1592, processing logic stores the index in the host organization's database.

  At block 1593, processing logic publishes the host organization's database via the request interface.

  At block 1594, processing logic receives, at the request interface, a query for the database that specifies the SIMILAR command term, the row specified as the parameter of the SIMILAR command term, and the column specified as the parameter of the SIMILAR command term. To do.

  At block 1595, processing logic queries the database, passing the specified row and the specified column, using the SIMILAR command term to generate a predicted record set.

  At block 1596, processing logic returns a predicted record set in response to the query. The predictive record set has multiple elements in it, and each of the returned elements of the predictive record set is (i) based on the specified column for the specified row passed in the SIMILAR command term. The latency between the row identifier corresponding to the rows of the dataset evaluated as similar according to the latent structure, and (ii) the specified row passed in the SIMILAR command and the row identifier returned for each element And a reliability index indicating the likelihood of the relationship.

  According to another embodiment of the method 1521, the column passed in the SIMILAR command term provides the context of the latent structure, in which case the specified row is similar to that returned by the elements of the predicted record set according to the latent structure. The row is evaluated for similarity.

  According to another embodiment of the method 1521, the rows of the dataset that were evaluated as being similar included in each element returned in the prediction record set were passed in the SIMILAR command term. Further based on the percentage of times that occur in the same row grouping as the specified row according to the column.

  According to another embodiment of the method 1521, querying the database using the SIMILAR command term to pass the specified row passes from the data set or index in the row identifier for the specified row. Including.

  According to another embodiment of method 1521, querying the database using the SIMILAR command term, passing the specified row, corresponds to all columns for the other rows in the dataset or index. Including passing the complete line listing name = value pairs in the SIMILAR command term.

  According to another embodiment of the method 1521, passing the complete row includes passing one or more null or blank values as values in the name = value pair.

  According to another embodiment, the method 1521 further includes a SIMILAR command term in response to the query based on (i) a returned predicted record set and a confidence measure for each similar row returned in the predicted record set. In response to a query based on the most similar row compared to the specified row passed in and (ii) the predicted record set returned and the confidence index for each of the similar rows returned in the predicted record set (Iii) a related product in a recommender system that has responded to a search by an Internet user in response to a search by an Internet user, the prediction record Including returning one of the related products corresponding to one of the similar rows returned in the set.

  According to another embodiment of the method 1521, querying the database using the SIMILAR command term may include the value of the specified row in the index and another row that exists in the index and corresponds to the specified column. Including estimating the mutual information based at least in part on the specified row so as to determine a measure of interdependence between the values of.

  According to another embodiment of the method 1521, the rows of the data set correspond to multiple documents stored as records in the original data set from which the index was generated, and passing the specified row is: Including passing one of a plurality of documents as a specified line, passing the document as a specified line using the SIMILAR command term, and querying the database is based on the content of the document Let the database perform the search.

  According to another embodiment, the method 1521 further includes passing a minimum confidence threshold in a SIMILAR command term, wherein returning the predicted record set is for a predicted record set having a confidence index that exceeds the minimum confidence threshold. Includes returning only elements.

  According to another embodiment, the method 1521 further includes passing an COUNT term that is an optional COUNT term that, when provided, specifies the maximum quantity of elements to be returned in the predicted record set. .

  According to another embodiment of method 1521, the elements of the predicted record set are returned in descending order according to a confidence index for each of the elements of the predicted record set, or alternatively, for each of the elements of the predicted record set Returned in ascending order according to the confidence index.

  According to another embodiment, the method 1521 further selects one or more of the similar rows from the predicted record set generated in response to querying the database using the SIMILAR command term for the similar rows. And identifying one or more of the similar rows in a second query that specifies a GROUP command term, and returning the second one returned from the second query. Limiting the predicted record set.

  According to another embodiment of the method 1521, publishing a host organization database includes publishing a Predictive Query Language Application Programming Interface (PreQL API) directly to an authenticated user, the PreQL API being Authenticated users can access via the public internet.

  According to another embodiment of the method 1521, querying the database using the SIMILAR command term includes passing a PreQL query to the database, where the PreQL query includes the SIMILAR command term as the required term and the required term. A ROW term that specifies the row to be passed in the SIMILAR command term, and a COLUMN term as the required term that specifies the column to be passed in the SIMILAR command term, and a COLUMN term An optional FROM term that specifies one or more tables, data sets, data sources and / or indexes to be queried when this optional FROM term is specified; 1 or more tables to be queried when not specified, the data set, the default value for the data source and / or index is used, has a FROM terms, the query syntax.

  According to another embodiment of the method 1521, the query syntax of the PreQL query is further an optional CONFIDENCE term that, when provided, specifies the minimum acceptable confidence measure to be returned in the predicted record set. A CONFIDENCE term and an optional COUNT term that, when provided, specifies the maximum quantity of elements to be returned in the predicted record set, and is provided with a COUNT term and an optional ORDER BY term One of the ORDER BY terms that specifies whether the elements of the prediction record should be returned in ascending or descending order according to a confidence measure for each of the elements returned in the prediction record set Provide multiple.

  According to another embodiment of the method 1521, querying the database using the SIMILAR command term includes passing a JavaScript Object Notation (JSON) structured query to the database, wherein the JSON structured query is: SIMILAR command term as the required term and any one or more tables, data sets, data sources and / or indexes to be queried, or one or more tables, data sets to be queried when not specified, Returned in the predicted recordset according to the default value of the data source and / or index, the row passed in the SIMILAR command term, the column passed in the SIMILAR command term, and the confidence index Predictive records according to an optional specification of the minimum acceptable confidence level, an optional specification of the maximum number of elements returned in the predicted record set, and a confidence measure for each of the elements returned in the predicted record set. It has a query syntax with an optional specification of whether elements should be returned in descending or ascending order.

  According to another embodiment of the method 1521, publishing a host organization database includes publishing a web form directly to an authenticated user, the web form being public to the authenticated user. Accessible via the Internet. The host organization generates a latent structure query for submission to the database based on the input from the web form. Querying the database using the SIMILAR command term includes querying the database using a latent structure query via the Predictive Query Language Application Programming Interface (PreQL API) within the host organization, where the PreQL API is the authenticated user Published indirectly through a web form.

  According to another embodiment of the method 1521, querying the database using the SIMILAR command term includes executing a Predictive Query Language (PreQL) structured query against the database for the SIMILAR command term. , The method further includes executing one or more additional PreQL structured queries against the database, wherein each of the one or more additional PreQL structured queries is PREDICT, SIMILAR, SIMILAR, and GROUP. Specifies at least one command selected from a group of PreQL commands including.

  According to another embodiment, the method 1521 further receives a data set from an authenticated subscriber and then receives a query to the database from the authenticated subscriber and generates an index. Processing the data set for the authenticated subscriber.

  According to another embodiment of method 1521, each of the plurality of rows in the data set corresponds to an entity, each of the plurality of columns corresponds to a characteristic for the entity, each respective row and a plurality of columns. The intersection point with each of these forms a cell and stores the value at the intersection point.

  According to another embodiment, there is a non-transitory computer readable storage medium having instructions stored thereon that, when executed by a processor in a host organization, generate an index from a column and row data set. The index represents a stochastic relationship between the rows and columns of the dataset, stores the index in the host organization database, and exposes the host organization database via the request interface. And at the request interface, receiving a query for the database specifying the SIMILAR command term, the row specified as the parameter of the SIMILAR command term and the column specified as the parameter of the SIMILAR command term; Generate set Using the SIMILAR command term to pass the specified row and the specified column, query the database, and return a predicted record set in response to the query, Each of the returned elements of the predicted record set has (i) a specified row passed in the SIMILAR command term, according to the latent structure, based on the specified column. The likelihood of a potential relationship between a row identifier corresponding to a row in the dataset evaluated as similar, and (ii) the specified row passed in the SIMILAR command and the row identifier returned for each element. Including a confidence measure to indicate to the host organization.

  FIG. 16A illustrates the use of a PREDICT command term according to the described embodiment. More specifically, the illustrated embodiment shows the use of classification and / or regression to query the index using the PREDICT command term, where the input 1601 to the PREDICT command term fixes a subset of columns, and , Output 1602 predicts a single target column. As can be seen from this example, the leftmost column will be predicted (eg, the output 1602 of the PREDICT command term) and several columns are provided as inputs 1601 to the PREDICT command term (eg, fifth, 7th, 8th, 11th, 12th, 13th and 16th columns).

  In the cross-categorization technique used to create the index, the prediction request presented via the PREDICT command term is treated as a new row for the data set, and the analysis engine uses this new in each cross-categorization. Assign rows to categories. The requested value is then predicted using the selected standard distribution for each category. Unlike traditional predictive analytics, the use of the analysis engine and the PREDICT command term provides a flexible predictive query without the need to customize the model specific to the data set being analyzed, thus allowing the user of the PREDICT command term to It allows to specify as many or as few columns as desired, and also allows the analysis engine to predict many or few elements according to user requirements.

  For example, consider a classification or regression in which all but one of the columns is used to predict a single target column. The analysis engine can render the prediction using a single target column, or it can render the prediction using several target columns at the user's discretion. For example, certain embodiments allow the user to query the index via the PREDICT command term and ask questions such as “Would the opportunity be closed and how much?”. Such a capability does not exist in the means conventionally available.

  In using the PREDICT command term, calling the appropriate API for the PREDICT functionality allows the user to predict any selected subset of data and predict any column or value. . It is not required that the entire data set be utilized to predict only a single value typical of custom implemented models.

  When using the PREDICT command term, the user provides or fixes an arbitrary column value, and then the PREDICT API call accepts the fixed value and what the user wants to predict. The PREDICT command term functionality then indexes (eg, via the analysis engine or PreQL, asking what will happen to the distribution given rows with these values fixed as provided by the user?). Query (eg through an interface or query interface). For example, this functionality may fix all columns except one in the data set, and then predict the last one, missing columns, as is done with customized models. However, the PREDICT command term functionality is more flexible than conventional models that are customized for a particular data set. For example, the user can change the columns to be predicted in a whim, while the custom-implemented model lacks a customized mathematical structure to predict for the unpredictable columns or studies described above Because it simply lacks this functionality. That is, there is no specific preprogrammed functionality, and conventional models are hard-coded to solve for specific columns, so this type of variable query cannot simply be executed. In contrast, the methodology described herein is not hard-coded or customized for any particular column or data set, as such, a user can distinguish multiple You can explore your data by making queries, or when your business needs change over time, the columns to be predicted, even if the underlying data and data structure of the client organization does not remain constant You can adapt your chosen query by simply changing.

  Also, perhaps the user does not know all the columns that should be fixed. For example, a data set may contain only limited observed values for one user but still have a large number of data for another user. For example, an e-commerce site may know little about unregistered passing users, but may know a lot of information about registered users with a rich purchase history. In these examples, the PREDICT command term functionality is fixed only on what is known, without requiring all users to ask for all data when some of the data is known to be missing. Therefore, the PREDICT command term easily adapts to missing data and null values present in the user's real-world data set. Thus, the PREDICT command term functionality can still predict missing data elements using data that is actually known.

  Another capability with the PREDICT command term functionality is to specify or fix all data in the known data set, ie all non-null values, and fill in everything else . Thus, the user can say that what is observed in the data set is known and can render predictions for the missing data. Therefore, the PREDICT functionality accepts predictions that have a prediction quality that exceeds the user's specified confidence level, and by utilizing the prediction data for missing or null values, Either the percentage will be increased, or all predicted values will be accepted by sufficiently reducing the minimum confidence threshold required by the user. This functionality is further implemented by the specialized GUI interface described herein.

  Another functionality using PREDICT is to fill the empty set. Thus, perhaps the data is totally missing for one particular entity row (or rows) and the PREDICT command term functionality can be used to generate composite data representing the new row. This new row represents composite data, but the new data in the row is valid.

  In other embodiments, PREDICT can be used to populate data elements that are not known, but should or should be present, but not yet filled in the data set, and therefore, PREDICT functionality. Makes it possible to populate the above data elements.

  Another example is using PREDICT to obtain the certainty or uncertainty for any element and display or return a reasonable range of values for the element.

  FIG. 16B illustrates the use of the PREDICT command term according to the described embodiment. More specifically, the illustrated embodiment illustrates the use of a “fill blank” technique, where missing data or null values in a tabular data set are pre-generated indexes. Is filled with the predicted value by querying with the PREDICT command term. Input 1611 to the PREDICT command term fixes a column subset, and output 1612 predicts all of the missing columns or missing elements (eg, null values) within the remaining missing columns.

  For example, the user can select an incomplete line (such as the top line drawn with multiple question marks), and via the PREDICT command term, the user can select all of the missing values to fill in the blanks. Can be predicted. In the extreme, the user specifies a table with many missing values across many rows and many columns as the data set to be analyzed, and then via the PREDICT command term, the user You can render a table where all white space is filled with values corresponding to different levels of quality.

  A specialized tool for this particular use case is discussed below, and its UI functionality allows the user to trade off reliability quality (eg, via a confidence score or confidence index) More data (or all data) can be populated by reducing the confidence level, or alternatively some not all data above a given confidence quality threshold configurable by the user It is possible to input more or less data into a table that can input. A use case specific GUI is further provided and described below in more detail for this particular use case. According to certain embodiments, the above GUI invokes the PREDICT command term via API for the user, but still utilizes the analysis engine functional core consistent with the methodology described herein. Then, a PreQL query based on the PREDICT command term is issued.

  FIG. 16C illustrates the use of the PREDICT command term according to the described embodiment. More specifically, the illustrated embodiment illustrates the use of a synthetic data generation technique that does not actually exist in any column or row of the original data set, but nevertheless. Data that is consistent with the data set is returned as composite data. Composite data generation again uses the PREDICT command term with inputs 1621 that are not fixed in any of the columns. Output 1622 results in all of the columns being predicted for the existing data set, as required by the user, and a single composite row is rendered, or multiple composite rows are rendered.

  Thus, the functionality described above can be used to fill the empty set with output 1622 by invoking the PREDICT command term without a column fixed at input 1621. For example, take an entity whose entity row data is totally missing, whether real or fictitious. By querying the index using the PREDICT command term, the analysis engine will generate data representing the empty set by providing a new entity row, and the composite data generated within the row range will be the composite data. However, it provides reasonable data. That is, the predicted values for the above rows do not derive from the data set as actually observed data, but still represent data that could be most likely observed in the data set. As already mentioned, a reliability quality index may be utilized to better match the output 1622 to the user's specific needs.

  Synthetic rows generated by the analysis engine in response to the PREDICT command term call are present in the actual data actually observed and as they exist in the data set analyzed by the analysis engine. One or more entity rows presenting all of the are output (1622). Such capabilities can allow users to generate and test realistic data sets, but allow users looking for such data to manually enter how such data might look or Without guessing, it does not hurt any actual individual real world data represented by entity rows in the dataset. This means that data sets for testing purposes are highly sensitive to personal financial data, personal healthcare data protected by HIPAA (Health Insurance Interoperability and Accountability Act), etc. Can be useful in situations where needed.

  FIG. 16D depicts an example architecture in accordance with the described embodiments. Specifically, customer organizations 1605A, 1605B and 1605C are depicted, each comprising client devices 1606A, 1606B and 1606C, including client devices 1606A, 1606B and 1606C sending queries and receiving responses. Ability to interface with host organization 1610 via network 1625. There is a request interface 1676 within the host organization 1610, which may optionally be implemented by the web server 1675. The host organization further includes a processor 1681, memory 1682, query interface 1680, analysis engine 1685, and multi-tenant database system 1630. There is execution hardware, software and logic 1620 within the multi-tenant database system 1630, and the execution hardware, software and logic 1620 is shared across multiple tenants of the multi-tenant database system 1630, the authenticator 1698, and the prediction database 1650, The prediction database 1650 is capable of storing an index generated by the analysis engine to facilitate returning a prediction record set in response to a query executed against the prediction database 1650.

  According to one embodiment, the host organization 1610 runs a system 1631 having at least one processor 1681 and memory 1682. System 1631 includes an analysis engine 1685 that generates an index from a column and row data set, where the index represents a stochastic relationship between the rows and columns of the data set. The system 1631 further includes a prediction database 1650 that stores the index and a request interface 1676 that exposes the prediction database to, for example, a user or client device 1606A-C, at least (i ) One or more column names that specify the PREDICT command term; (ii) one or more specified columns to be predicted; and (iii) a column name to be fixed and a value to fix the column name. A request interface 1676 that receives a query 1653 specifying a = value pair. According to the above system, the query interface 1680 uses an index stored in the database 1650 to determine the simultaneous conditional distribution of one or more specified columns to be predicted that are fixed according to column name = value pairs. The prediction database 1650 is queried (1653) using the PREDICT command term to pass the one or more specified columns to be predicted and one or more column name = value pairs to generate a representation. For example, the PREDICT command term and its operands (one or more column IDs and one or more column names = value pairs) can be executed against the prediction database 1650.

  In the above system 1631, the request interface 1676 further returns a representation of the simultaneous conditional distribution of one or more specified columns as output 1654 in response to the query 1653.

  FIG. 16E is a flow diagram 1632 illustrating one method in accordance with the disclosed embodiments. Method 1632 may be performed by processing logic that includes hardware according to a system, apparatus, and method for implementing a PREDICT command with a predictive query interface as described herein (eg, Circuit, dedicated logic, programmable logic, microcode, etc.), software (eg, send, send, receive, execute, generate, calculate, store, publish, query, process, etc. on the processing device to perform various operations Instructions to be executed) and the like. For example, the host organization 110 of FIG. 1, the machine 400 of FIG. 4, or the system 1631 of FIG. 16D may implement the described methodology. Some of the blocks and / or operations listed below are optional in certain embodiments. The block numbering presented is for clarity and is not intended to define the order in which the various blocks should occur.

  At block 1691, processing logic generates an index from the column and row data sets. The index represents a probabilistic relationship between the rows and columns of the data set.

  At block 1692, processing logic stores the index in the host organization's database.

  At block 1693, processing logic publishes the host organization's database via the request interface.

  At block 1694, processing logic at the request interface, at least (i) a PREDICT command term, (ii) one or more specified columns to be predicted, and (iii) columns to be fixed, for the database. A query specifying one or more column name = value pairs specifying a name and a value for fixing the column name is received.

  For example, one or more column name = value pairs passed in the PREDICT command term according to (iii) above are merely examples: column_abc = 'string_xyz', or {column_abc = 'string_xyz'}, or column_abc = | 'string_xyz' It can take the form of Other syntaxes are acceptable depending on the API and / or query interface that accepts the query. Furthermore, a plurality of the above column name = value pairs may be passed.

  At block 1695, processing logic uses the index stored in the database to generate a representation of the simultaneous conditional distribution of one or more specified columns to be predicted that are fixed according to column name = value pairs. In addition, the PREDICT command term is used to query the database, passing one or more specified columns to be predicted and one or more column name = value pairs.

  Processing logic may further return a representation of a simultaneous conditional distribution of one or more specified columns as output, for example, in a predicted record set in response to a query.

  According to another embodiment, the method 1632 further includes generating a predictive record set in response to the query, wherein the predictive record set includes a plurality of elements therein, each of the elements being predicted. Specifies a value for each of one or more specified columns to be powered. The method further includes returning a predicted record set in response to the query.

  According to another embodiment of the method 1632, publishing the host organization database includes publishing a Predictive Query Language Application Programming Interface (PreQL API) directly to the authenticated user, the PreQL API being Authenticated users can access via the public internet.

  According to another embodiment of the method 1632, querying the database using the PREDICT command term includes passing a PreQL query to the database, the PreQL query being predicted with a PREDICT command term as the required term. Specify one or more specified columns to be specified, specify the required TARGET term, the column name to be fixed and the value for fixing the column name as one or more column name = value pairs; Query a predicted record set that has the required WHERE terms and returns elements that are stochastically related to one or more columns to be fixed as specified and the corresponding values to fix the columns WHERE term and optional FROM term that restricts the output of this, and this optional FROM term is specified Specifies one or more tables, data sets, the data source and / or index to be interrogated when he has a FROM terms, the query syntax.

  According to another embodiment of the method 1632, querying the database using the PREDICT command term includes passing a JavaScript Object Notation (JSON) structured query to the database, wherein the JSON structured query is: A PREDICT command term as a required term, a required specification of one or more specified columns to be predicted, a column name to be fixed as one or more column name = value pairs, and the column name A required specification of a value to fix, and the corresponding one or more columns to be fixed as specified via one or more column name = value pairs and corresponding to fix the column Queries the specification to limit the output of the query to a predicted recordset that returns elements that are stochastically related to the value It has a query syntax with an optional specification of one or more tables, data sets, data sources and / or indexes.

  According to another embodiment of the method 1632, publishing the host organization database includes publishing the web form directly to the authenticated user, the web form being public to the authenticated user. Accessible via the Internet.

  According to another embodiment of the method 1632, the host organization generates a predictive query to submit to the database based on input from the web form. Querying the database using the PREDICT command term includes querying the database using a predictive query via a predictive query language application programming interface (PreQL API) within the host organization, and the PreQL API is used to authenticate users. Published indirectly through a web form.

  According to another embodiment, the method 1632 further includes returning a predicted record set that specifies predicted values for each of the columns originally in the data set.

  According to another embodiment, the method 1632 further includes returning a composite data set in response to the query, wherein the composite data is originally provided in the data set according to a stochastic relationship of indices in rows and columns. Contains composite rows with data consistent with the rows and columns, but does not include any original records of the data set.

  According to another embodiment of method 1632, returning the composite data set includes anonymizing financial records from the data set, anonymizing medical records from the data set, and Internet from the data set. It includes at least one of making the user record anonymous.

  According to another embodiment, the method 1632 further includes returning a distribution based on a probabilistic relationship between the rows and columns of the data set using an index, wherein the returned distribution includes: Contains composite data from an index that is mathematically derived from the row, but contains information about the data that was not in any original record of the dataset, and the index from which the distribution was derived is Is not constrained by the data range of the original record.

  According to another embodiment, the method 1632 is further a confidence score for the distribution, ranging from 0 to 1, where 0 indicates that the predicted value is not confident, 1 being at the predicted value At least one of a confidence score that indicates the maximum possible confidence and a confidence interval that indicates the minimum and maximum values, and where there is a clear confidence that a value exists between the intervals. Including returning.

  According to another embodiment of the method 1632, returning a distribution based on a probabilistic relationship is passing an optional record count term in the PREDICT command term when querying the database, the optional record The count term specifies the quantity of records to be returned in response to the query, and determines the required quantity of processing resources required to return the record with the quantity specified by the record count. In addition.

  According to another embodiment of method 1632, returning a distribution based on a probabilistic relationship is to pass a minimum precision threshold with the PREDICT command term when querying the database and to satisfy the minimum precision threshold as a lower bound. Determining the required population of samples to be returned.

  According to another embodiment of the method 1632, querying the database using the PREDICT command term includes executing a Predictive Query Language (PreQL) structured query against the database for the PREDICT command term. The method further includes executing one or more additional PreQL structured queries against the database, each of the one or more additional PreQL structured queries being PREDICT, RELATED, SIMILAR, and GROUP. Specifies at least one command selected from a group of PreQL commands including.

  According to another embodiment, the method 1632 further receives a data set from an authenticated subscriber, then receives a query against the database from the authenticated subscriber and generates an index. Processing the data set for the authenticated subscriber.

  According to another embodiment of method 1632, each of the plurality of rows in the data set corresponds to an entity, each of the plurality of columns corresponds to a characteristic for the entity, each respective row and a plurality of columns. The intersection point with each of these forms a cell and stores the value at the intersection point.

  According to another embodiment, there is a non-transitory computer readable storage medium having instructions stored thereon that, when executed by a processor in a host organization, generate an index from a column and row data set. The index represents a stochastic relationship between the rows and columns of the dataset, stores the index in the host organization database, and exposes the host organization database via the request interface. In the request interface, at least (i) a PREDICT command term, (ii) one or more specified columns to be predicted, and (iii) a column name to be fixed and the column name for the database. Receives a query that specifies one or more column name = value pairs that specify the value to be fixed And a PREDICT command to generate a representation of the simultaneous conditional distribution of one or more specified columns to be predicted, fixed according to column name = value pairs, using an index stored in the database The term is used to cause the host organization to perform operations including querying the database passing one or more specified columns to be predicted and one or more column name = value pairs.

  FIG. 16F depicts an example architecture in accordance with the described embodiments. The embodiment depicted here is that the query 1657 specifying the PREDICT command term is used with a fixed number of columns, ie, no column ID passed in the PREDICT command term. Same as 16D embodiment. As a result, the output 1658 returned in response to the query 1657 provides generated composite data having one or more entity rows with predicted values for every column of the data set.

  According to one embodiment, the host organization 1610 runs a system 1635 having at least one processor 1681 and memory 1682. System 1635 includes an analysis engine 1685 that generates an index from the column and row data sets, where the index represents a stochastic relationship between the rows and columns of the data set. The system 1635 further includes a prediction database 1650 that stores the index and a request interface 1676 that exposes the prediction database to, for example, a user or client device 1606A-C, and receives a query 1657 against the database 1650. The query interface 1676 includes a request interface 1676, and the query 1657 specifies zero PREDICT command terms, and zero columns are fixed so that column IDs are not passed in the PREDICT command terms. In the above system, the query interface 1680 may generate any specified column to produce as output the generated composite data having one or more entity rows with predicted values for every column of the data set. The prediction database 1650 is queried using the PREDICT command term without any action (1657). In the system 1635 described above, the request interface 1676 further outputs generated composite data having one or more entity rows with predicted values for every column of the data set as output 1658 in response to the query 1657. return.

  FIG. 16G is a flow diagram 1633 illustrating one method in accordance with the disclosed embodiments. Method 1633 may be performed by processing logic that includes hardware according to a system, apparatus, and method for implementing a PREDICT command with a predictive query interface as described herein (eg, Circuit, dedicated logic, programmable logic, microcode, etc.), software (eg, send, send, receive, execute, generate, calculate, store, publish, query, process, etc. on the processing device to perform various operations Instructions to be executed) and the like. For example, the host organization 110 of FIG. 1, the machine 400 of FIG. 4, or the system 1635 of FIG. 16F may implement the described methodology. Some of the blocks and / or operations listed below are optional in certain embodiments. The block numbering presented is for clarity and is not intended to define the order in which the various blocks should occur.

  At block 1670, processing logic generates an index from the column and row data sets. The index represents a probabilistic relationship between the rows and columns of the data set.

  At block 1671, processing logic stores the index in the host organization's database.

  At block 1672, processing logic publishes the host organization's database via the request interface.

  At block 1673, processing logic receives, at the request interface, a query that specifies a PREDICT command term and one or more specified columns to be passed in the PREDICT command term for the database.

  At block 1674, processing logic queries the database using the PREDICT command term and one or more specified columns to generate output. The output includes generated composite data having one or more entity rows with predicted values for every column of the data set using an index stored in the database.

  Processing logic may further return the generated synthetic data as output, for example, in a predicted record set in response to a query.

  According to another embodiment, the method 1633 is further generated in response to querying as a composite data set having one or more entity rows with predicted values for every column of the data set. Including generating composite data, the generated composite data including composite rows with data consistent with the rows and columns originally provided in the data set, according to the probabilistic relationship of the indexes in the rows and columns. Does not contain any original records in the dataset.

  According to another embodiment of method 1633, returning the composite data set includes anonymizing financial records from the data set, anonymizing medical records from the data set, and Internet from the data set. It includes at least one of making the user record anonymous.

  According to another embodiment, there is a non-transitory computer readable storage medium having instructions stored thereon that, when executed by a processor in a host organization, generate an index from a column and row data set. The index represents a stochastic relationship between the rows and columns of the dataset, stores the index in the host organization database, and exposes the host organization database via the request interface. In the request interface, specify a PREDICT command term for the database and receive a query with a zero column that is fixed so that no column ID is passed in the PREDICT command term, and generate output. , PREDICT command term and one or more specified Querying the database using columns, the output having one or more entity rows with predicted values for every column of the data set using an index stored in the database. Including the generated composite data, and causing the host organization to perform an operation including:

  FIG. 17A depicts a graphical user interface (GUI) 1701 for displaying and manipulating a tabular data set having missing values by utilizing the PREDICT command term. More specifically, a GUI is provided to the user in the display interface, and the user uploads or specifies a data set having columns and rows, and then displays this data set as a table, with the missing values in this table. Permits an operation by inputting a predicted value (for example, a null value). At element 1707, the user specifies data to be analyzed and displayed via the GUI 1701. For example, a user can browse a local computing device for a file, such as an Excel spreadsheet, and then upload this file to the system for analysis, or the user can instead provide a GUI 1701. You can specify a dataset that is accessible to your host organization. For example, if the host organization is a cloud-based service provider and the user's dataset already exists in the cloud, the user simply designates the dataset as a data source via the action in element 1707. be able to.

  In the example depicted in FIG. 17A, the displayed table provided by the user is 61% filled. This table is only partially filled because the provided user data set has many missing data elements. The value currently displayed in grayscale depicts a known value, for example, the known value “1.38” in the top row in the Proanthocyanine column depicted by element 1703. In the Proline column, two columns to the right, there is a null value represented in the top row, represented simply by an empty cell as depicted by element 1702.

  In this initial plot, all known values 1703 are drawn and correspond to the actual observed data in the underlying data set. According to this embodiment, the slider 1705 acting as a threshold corrector is at the left-hand end and is the minimum fill when all known values are displayed without displaying any predicted value. ) 1704. Thus, the reliability of all displayed values can be considered 100% if all values are actually observed in the provided data set and no values are predicted. The slider control can be used as a threshold modifier that controls the fill percentage of the table, which also modifies the confidence threshold needed to achieve the user specified fill percentage. Alternatively, the slider control can be used as a threshold modifier to control the user's acceptable uncertainty level, so when the user's specified acceptable uncertainty level changes, the table fill The percentage will increase or decrease according to the available predicted value that conforms to the user's specified acceptable level of uncertainty. In other embodiments, an acceptable level of uncertainty may be specified, for example, via a text entry box or other control means.

  The user can click the download 1706 action to download the displayed table in various formats, but these tables correspond to the source table just specified or uploaded via the data 1707 action. become.

  Although the value is not predicted, the user may simply move the slider to increase the data fill for the missing value and let the GUI functionality utilize the prediction function for the user. Just above the slider, the user is informed of the current state of the minimum fill 1704, which is 61% as described above according to the displayed example, but changes as the slider is moved. become.

  FIG. 17B depicts another view of the graphical user interface. Here, the displayed table is populated with predicted values for some but not all of the null values (eg, missing data). For example, a previously empty cell in the top row in the Proline column that corresponded to a null value in the user's underlying data set would have the predicted value “564” as depicted by element 1708. Here it has been introduced. In particular, the value 564 was not present at this location in the user's underlying data set and was not observed in the user's underlying data set. Rather, the GUI 1701 configures a PREDICTED command term call for the user to retrieve the result of the predicted value 1708 and display it here. In this example, all of the values in grayscale are known values, and all of the values in the table displayed in solid black are predicted to replace previously unknown null values in the same data set. Value.

  The slider now shows 73% fill, as depicted by element 1709, with some but not all missing values being populated with predicted values here. The fill level is user-controllable by simply moving the slider back and forth, and the GUI 1701 predicts the missing data value when the user's specified acceptable uncertainty level is increased or decreased, respectively. The entered value is input or the predicted value is removed.

  Not depicted in this example is a user configurable minimum confidence threshold, which may be set via a text box, drop-down, slider, etc. These GUI elements allow the user to specify the minimum confidence necessary for the predicted value to be displayed on the GUI 1701. In one embodiment, having a minimum confidence threshold further results in the maximum fill value being displayed, and then the slider in element 1709 is limited to the maximum fill, as limited by the minimum confidence threshold. .

  This is because when the fill percentage increases, it is necessary to reduce the reliability quality of the predicted value that is put into the null value. Conversely, reliability quality can increase when the fill percentage decreases.

  Thus, if the user commands perfect (eg, 100%) reliability quality, it is unlikely that any missing value will be predicted with 100% confidence, so filling any null value is It's not possible. However, all actually observed values will continue to be displayed because they are known from the underlying data set with 100% confidence. Conversely, if the same user commands a very low confidence (eg, 25%), the 25% requirement is a low threshold in terms of confidence quality, so most, if not all, missing values are predicted Likely to be able to. Depending on the quality of the underlying dataset, the size of the population in the underlying dataset, etc., all or nearly all null values can be predicted with a relatively high (eg 80%) confidence However, it can be realized with several data sets. Regardless of this, the GUI 1701 does not even need to understand how the PREDICT command term works, what input it requires, how to make a PreQL or JSON API call, etc. Allows to try in a fairly intuitive way. Such a GUI 1701 can thus greatly reduce the learning curve of a general user who wants to take advantage of the predictive capabilities provided by the core of the analysis engine.

  FIG. 17C depicts another view of the graphical user interface. Here, the GUI 1701 has its pre-drawn known value 1703 and predicted value 1708, but the user-controllable slider has a right edge up to 100% maximum fill as depicted by element 1709. Thus, all known values remain in the table display, but 100% of the null values in the data set are also populated and displayed on the GUI 1701.

  In addition, element 1710 shows a minimum confidence threshold action as an optional input field that specifies the minimum confidence threshold described so far (eg, via a drop-down, text box, slider, radio button, etc.). Has been. Some tables can be displayed at 100% using a minimum confidence threshold greater than zero, while if the minimum confidence threshold is specified at 1710, the quality of the underlying data set is insufficient Some tables require that the threshold may need to be at or near zero. Such a decision will deviate from the data set according to the stochastic correlation of the data elements and the presence or absence of noise.

  Regardless of the above, the minimum confidence threshold specified at 1710 allows a general user to try his data set in a fairly intuitive manner. If the user specifies a minimum confidence threshold that does not allow 100% fill at 1710, then the maximum percent filled or fill percentage is set by the user at 1710 when the slider is moved to the right edge. The degree of fill that can be realized according to the minimum reliability threshold is shown.

  Since the table is displayed with 100% fill, all null or missing values are predicted, but it may be necessary to somewhat reduce the confidence to achieve 100% fill. In this case, the optional minimum confidence threshold at 1710 may remain unset, grayed out, not activated, or simply not displayed to the user.

  According to certain embodiments, the selected fill level or acceptable uncertainty level that is selected by the user via the slider bar (or controlled via an optional minimum confidence threshold at 1710). Can be “saved” by clicking on the download action to capture the displayed data set. The displayed copy can be saved as a new version or at the user's discretion over the original version of the table. Thus, the provided prediction value is saved or results in the cell location in the user's local copy being entered. In addition, metadata may be used to distinguish predicted values from actual known and observed values, thus subsequent use of the data set is corrupted or erroneously caused by user trial activity Not affected.

  The reason why the control slider in element 1709 is feasible is that for the GUI functionality that makes a PREDICT command term API call when the user asks for a value to be predicted, such as a missing value of “income”. What is returned is the income distribution of each individual as predicted by analysis engine modeling to generate the index, and then the index is queried by the PREDICT command term. The returned distribution for the predicted value allows the GUI to select the value to be displayed and to limit the display according to the confidence quality. In other embodiments, a confidence measure is returned rather than a distribution.

  By generally using the above GUI interface or the above concept, the user is given control over accuracy and reliability. Thus, the user can manipulate how much data will be filled and if so, to what extent the reliability quality threshold will be applied. Behind the scenes and not visible to the user, the GUI 1701 makes a PREDICT command term API call to the analyzed data set specified by the user. The analysis engine picks up the user's dataset, eg, a table with a large number of types of columns, and then renders the prediction for every single cell that has a null value in the GUI 1701 request. For each missing cell, the GUI 1701 returns a distribution or confidence index from the PREDICT command term API call, and when the slider is manipulated by the user, the GUI slider functionality examines the distribution for null values. Examine the variance for the distribution of null values and then display the estimate as the predicted value shown in the example. Thus, for any given cell that has a predicted result in place of a missing null value, the GUI 1701 by leveraging the PREDICT command term functionality can cause multiple other known values in the underlying data set. Alternatively, the value for the null value is represented to the user based on examining the observed value. The GUI 1701 itself does not perform data set analysis, but benefits exclusively from the data returned from the PREDICT command term API call as described above.

  According to one embodiment, data is uploaded to a prediction database, including only raw data in tabular form, such as data in a spreadsheet, data stored in one or more tables of a relational database, etc. Or, for insertion, an UPLOAD command term API call is first made by the GUI. In the prediction database, an analysis engine operates to analyze the data either automatically or in response to an ANALYZE command term API call. For example, if a user pays a service fee for access to this functionality, the GUI may indicate pricing to the user when data is uploaded and require acceptance before triggering analysis by the analysis engine. . In other examples, the analysis engine simply performs the analysis automatically. Regardless of the above, once the data specified by the user is uploaded, the data just looks like all other tabular data, but once uploaded and analyzed by the analysis engine, the probabilistic model Is performed on the data, and through its modeling, the learning engine learns how the rows and columns interact with each other, through which various probabilistic and causal relationships are built and described herein. Represented in the generated index as specified. For example, the generated statistical index may show how columns are related to each other and which columns are related to each other, for example to learn that a particular subset of columns are likely to share causal origin. Find out what you are doing.

  The analysis engine performs its analysis with real-world data provided by the user rather than a clean and complete data set, often doing the above without knowing in advance the underlying structure of the data to be analyzed It must be a difficult problem. In real-world data, some columns are worthless, some columns are duplicates, some columns are heterogeneous (for example, not consistent data types), how many These columns are simply noise with sparsely populated data, or are populated with noisy and erroneous data. The analysis engine identifies appropriate relationships and causal relationships through its analysis index and other modeling, despite the lack of perfectly clean data or standardized data structures.

  Through statistical indexing and other modeling, the distribution of the index results in a model stored as a queryable index in support of predictive queries, including queries utilized by the described GUI 1701. Other specialized GUI and API tools that further utilize the PREDICT command term and other predictive PreQL queries include business opportunity scoring, identification of the next best offer, and so on. These and other examples are described in further detail later herein.

  FIG. 17D depicts an example architecture in accordance with the described embodiments. Specifically, customer organizations 1705A, 1705B, and 1705C are depicted, each comprising a user's client device and display 1706A, 1706B, and 1706C, and the user's client device and display 1706A, 1706B, and 1706C are used to enter, query, and Capability to interface with host organization 1710 via network 1725, including sending requests and responsively receiving responses including output for display. Within the host organization 1710 is a request interface 1776, which may optionally be implemented by the web server 1775. The host organization further includes a processor 1781, memory 1782, query interface 1780, analysis engine 1785, and multi-tenant database system 1730. There is execution hardware, software and logic 1720 in the multi-tenant database system 1730, and the execution hardware, software and logic 1720 is shared across multiple tenants of the multi-tenant database system 1730, the authenticator 1798 and the prediction database 1750, The prediction database 1750 is capable of storing an index generated by the analysis engine 1785 to facilitate returning a prediction record set in response to a query executed against the prediction database 1750.

  According to one embodiment, the host organization 1710 runs a system 1711 having at least one processor 1781 and memory 1782. System 1711 includes a request interface 1776 that receives a tabular data set 1753 from a user as input, the tabular data set including data values organized as columns and rows. The user can provide the tabular data set 1753 as a file attachment or can specify the location of the tabular data set 1753. The system 1711 further includes an analysis engine 1785 that identifies a plurality of null values in the tabular data set 1753 received from or specified by the user, the null values being a plurality of values in the tabular data set 1753. Are scattered across rows and columns. In one such embodiment, the analysis engine 1785 further generates an index 1754 from the column and row tabular data set, which represents a stochastic relationship between the rows and columns of the tabular data set 1753. Request interface 1776 returns a tabular data set to the user as display output 1755, which includes a data value drawn as a known value and a null value drawn as an unknown value. Request interface 1776 further receives input 1756 for input from the user. The input can be, for example, an input via slider control, a user-specified minimum reliability threshold, or the like. Input for input 1756 received from the user inputs predicted value 1758 in which at least a portion of the unknown values in the displayed tabular data set is retrieved from an index stored in prediction database 1750. Specify what will be done. The predicted value 1758 is returned from an index stored in the prediction database 1750 in response to a query 1757 constructed and issued against the prediction database 1750 by the analysis engine 1785 and / or the query interface 1780. Can do.

  For example, in the system described above, the query interface 1780 can query the index for the expected value 1758 (eg, via the query 1757), after which the request interface 1776 can display the user's client device and display 1706A. Return the predicted value 1758 as an updated display output 1759 to the user via -C. For example, the updated display output then corresponds to the previously drawn unknown or null value entry corresponding to the missing data or null value entry in the original tabular data set 1753 provided or specified by the user. Instead of the value, the user's client device and displays 1706A-C are drawn here to draw the predicted value.

  According to another embodiment, the system 1711 further includes a prediction database 1750 that stores indexes generated by the analysis engine. In one such embodiment, the prediction database 1750 is implemented for one or more subscribers at the host organization 1710 as an on-demand cloud-based service.

  In another embodiment, the system 1711 further includes an authenticator 1798 that verifies the user (eg, the user at one of the user's client device and display 1706A-C) as a known subscriber. The authenticator 1798 then operates to further verify the authentication credentials presented by the known subscriber.

  In another embodiment, the system 1711 is further a web server 1775 that implements a request interface, and as input, one or more of a plurality of customer organizations that interface with a host organization over a network. A web server 1775 that receives a plurality of access requests from a client device, and a multi-tenant database system with predictive database functionality that implements a predictive database. Each customer organization is selected from a group consisting of a separate and distinct remote organization, an organizational group within the host organization, a business partner of the host organization, or a customer organization that subscribes to cloud computing services provided by the host organization Entity.

  FIG. 17E is a flow diagram illustrating one method according to a disclosed embodiment. Method 1721 may be performed by processing logic that includes hardware according to a system, apparatus, and method for displaying a tabular data set and predicted values on a user display as described herein. To perform various operations such as hardware (eg, circuit, dedicated logic, programmable logic, microcode, etc.), software (eg, send, send, receive, execute, generate, calculate, store, publish, query, process) Instructions executed on the processing device) and the like. For example, the host organization 110 of FIG. 1, the machine 400 of FIG. 4, or the system 1711 of FIG. 17D can implement the described methodology. Some of the blocks and / or operations listed below are optional in certain embodiments. The block numbering presented is for clarity and is not intended to define the order in which the various blocks should occur.

  At block 1791, processing logic receives a tabular data set from the user as input. The tabular data set has data values organized as columns and rows.

  At block 1792, processing logic identifies a plurality of null values in the tabular data set. The null values are scattered across multiple rows and multiple columns of the tabular data set.

  At block 1793, processing logic generates an index from the tabular data set of columns and rows. The index represents a stochastic relationship between the rows and columns of the tabular data set.

  At block 1794, processing logic displays the tabular data set as output to the user. The displayed output includes data values drawn as known values and null values drawn as unknown values.

  At block 1795, processing logic receives input from the user to populate the predicted value for at least a portion of the unknown values in the displayed tabular data set.

  At block 1796, processing logic queries the index for the predicted value.

  At block 1797, processing logic displays the predicted value to the user as an updated output.

  In particular, blank values represented by “unknown values” or “null values” in the dataset may occur anywhere in the tabular dataset, but must be analyzed by the core of the analysis engine. Allows the user to intuitively search the data set, and the data according to various criteria, eg, minimum confidence threshold, user configurable slider mechanism, etc. presented via the GUI of FIGS. 17A-17C Allows users to fill in values seamlessly wherever they are missing. Microsoft's Excel program is very good at computing down the next column or down to the next row based on the algorithm, but such a conventional spreadsheet program has multiple unknown values, especially in a single row, or When there are multiple missing values in a single column, missing values or holes in the data set across different rows and different columns cannot be tolerated.

  Tabular data sets that are analyzed and displayed back to the user do not work by copying a known algorithm to another cell location based on the relative location so that the Excel spreadsheet can work. Rather, the insertion and display of values that are missing or unknown to the user is based on querying and receiving the expected value for each cell location, and the respective cell location is returned to the user for display. Displayed to the user in a tabular data set. This is enabled through the analysis and generation of an index based on the probability from the originally received data set. Traditional solutions such as Excel spreadsheets simply do not perform the above analysis and do not generate the above index. As such, conventional solutions cannot render predicted values for multiple missing cells that span multiple rows and columns of a data set.

  According to one embodiment, predictions for all missing cells are determined for the entire received tabular data set. Then, when the user selects a particular certainty level (eg, minimum confidence level, etc.), the display is updated with a value that meets the criteria. For example, cells with missing values and having predicted values with corresponding confidence measures that exceed a default threshold or a user-specified threshold can be displayed to the user.

  According to another embodiment of the method 1721, generating the index from the column and row tabular data set further includes storing the index in a host organization database and querying the index for expected values. This includes querying the database for expected values.

  According to another embodiment of the method 1721, receiving input from the user to populate the predicted value for at least a portion of the unknown values in the displayed tabular data set includes displaying the displayed table. Querying the index for predicted values, including receiving input from the user that populates the predicted values for all unknown values in the format data set, is any null identified in the tabular data set. Displaying the predicted value to the user as an updated output, including querying the index for the predicted value for the value, replaces all unknown values by displaying the corresponding predicted value Including doing.

  According to another embodiment of the method 1721, multiple null values in a tabular data set are not restricted to any row or column of the tabular data set, with the predicted value as an updated output. Displaying to the user replaces unknown values displayed in a tabular data set without any restrictions on any row or column and without changing the index on which the predicted value is based.

  According to another embodiment of method 1721, querying the index for predicted values includes querying the index for each and each of a plurality of identified null values in the tabular data set, wherein The method further includes receiving a predicted value for each and each of a plurality of identified null values in the tabular data set in response to querying, and outputting the predicted value to the updated value. As to the user includes displaying the received predicted value.

  According to another embodiment of the method 1721, querying the index for predicted values may include a prediction specifying a PREDICT command term for each and every identified plurality of null values in the tabular data set. Generating a query language (PreQL) query, issuing each of the generated PreQL queries to a predictive query language application programming interface (PreQL API), and responding to the issued PreQL query in tabular form Receiving a predicted result for each and every identified plurality of null values in the data set.

  According to another embodiment of the method 1721, displaying the tabular data set further includes displaying the known values in the spreadsheet cells using black text and the unknown values in the spreadsheet. Displaying as a blank cell and displaying the predicted value in a cell of the spreadsheet using colored or grayscale text.

  According to another embodiment of the method 1721, displaying the predicted value to the user as an updated output displays the updated output in a spreadsheet or table in a graphical user interface (GUI). The known value is displayed as a cell populated in a spreadsheet or table in the GUI in the first type of text, and the predicted value is the first type of text corresponding to the known value In the second type of identifiable text, it is displayed as a cell populated in the spreadsheet or table in the GUI, and any remaining unknown values are displayed as empty cells in the spreadsheet or table in the GUI. The

  According to another embodiment of the method 1721, displaying the tabular data set to the user as output and displaying the predicted value to the user as an updated output is in a graphical user interface (GUI). Including displaying tabular data sets and predicted values in a spreadsheet or table, the GUI is further controllable by a user to specify an acceptable degree of uncertainty for the spreadsheet or table Receiving input from a user including a slider interface to populate a predicted value for at least a portion of unknown values in a displayed tabular data set is accepted as input from the user via the slider interface Including receiving possible degrees of uncertainty. .

  According to another embodiment, the method 1721 further includes displaying a minimum fill percentage for the GUI, the minimum fill percentage being between all null values and all known values for the tabular data set. Corresponds to the percentage of the known value in the tabular data set of the grand total.

  According to another embodiment of the method 1721, a slider interface that can be controlled by the user to specify an acceptable degree of uncertainty for a spreadsheet or table is used to fully populate the displayed tabular data set. Is limited to a range that includes the maximum degree of uncertainty required for the minimum fill percentage.

  For example, completely populating the displayed tabular data set will result in a fill percentage of 100%, but it is not necessary for the user to specify an acceptable degree of uncertainty equal to 100%. Rather, the displayed tabular data set achieves a fill percentage of 100% (eg, every single null or unknown value, for example, at a user specified acceptable degree of uncertainty of 50%) It may be feasible to input the predicted result. Regardless of which acceptable degree of uncertainty the user specifies, when the acceptable degree of uncertainty is increased, a larger portion of the table will be filled, and the degree of acceptable uncertainty will be reduced. As a result, a smaller part of the table will be filled. Thus, the user is allowed to dynamically search in a very intuitive manner how the predicted reliability affects the displayed result.

  According to another embodiment, the method 1721 further includes a GUI spreadsheet or 100% fill percentage in response to user input specifying a maximum acceptable degree of uncertainty via a slider interface. By populating the table and, for each of multiple null values in the tabular data set, reducing the required confidence for each of the predicted values until the predicted value is available, Including throwing in all null values.

  An unknown value corresponds to data that is simply missing from the tabular data set, while a known value can be defined as a value that is truly certain because the data was actually observed. Thus, the initial presentation of the tabular data set returned to the user as output can include all values that are truly certain, ie the initial output is the original tabular data set in a table or spreadsheet type format. All values actually observed within can be returned and simply displayed. Therefore, the unknown value is still missing. However, such a display can be displayed with 100% confidence because only known data is displayed. Thus, the level of fill or the degree of input for the displayed output corresponds to the minimum fill percentage, a value that can be displayed to the user.

  In the opposite position, the user may request to see a fully populated table even though the originally presented tabular data set has unknown values. This can be achieved by presenting the user with all predicted values that have a certainty greater than zero, and therefore fully fill or fill the displayed table. Can be defined as When fully filling the table, any white space identified will be provided for display of the predicted value regardless of the confidence in the predicted value. Thus, all values between “0” certainty and “1” certainty are displayed. Although such a view is available to the user, this display further indicates that the certainty value for the predicted value is inadequate, or the confidence for the predicted value with the lowest reliability quality. May show a degree score. In an alternative embodiment, the user can specify a minimum confidence quality threshold, and then the displayed value will be limited based on the user designated minimum confidence quality threshold. If the user-specified minimum reliability quality threshold is specified to be greater than zero, the maximum fill percentage is likely to be unpredictable with a confidence that exceeds the user-specified minimum reliability quality threshold. Therefore, it may be less than 100%.

  Thus, according to another embodiment, method 1721 further provides a user-controllable minimum confidence threshold in a graphical user interface (GUI) that displays a tabular data set as output to the user in a spreadsheet or table. Displaying a predicted value as an updated output to a user, including displaying and receiving a user-specified minimum reliability threshold as input via a user-controllable minimum reliability threshold Includes displaying only predicted values in the GUI that have a corresponding confidence measure equal to or greater than a user-specified minimum confidence threshold.

  In certain embodiments, a query is constructed and issued for every missing cell or unknown value in the tabular data set, and then a prediction is returned in response. Taking one of these missing values as an example, a confidence measure can be returned as the value, or a distribution allowing further analysis. For example, for a particular missing cell, take this cell as an example to query for the predicted true | false value. This query may return exemplary 100 prediction results. Perhaps 75 of the predictions return true and 25 of the predictions return false. Thus, it can be said that the predicted value has a certainty of 75% that is true. This 75% certainty can then be compared against a threshold to determine whether to display a value. However, besides the basic example described above, there are many other ways of calculating the confidence or confidence measure. In more complex examples, for example, the prediction results for true | false values were 50-50 such that the prediction results returned as 50 true and 50 false. In such a case, the result is 50% true and 50% true, but the 50-50 result is also maximally uncertain. In other words, this 50-50 result is the least probable result possible and therefore corresponds to the greatest uncertainty.

  The prediction is not simply true | false. For example, take a null value for an RGB field with a closed set with the possibility of three colors red, green and blue. Here, the prediction may return 100 exemplary guesses or predictions as before, but here it tries to predict the color value as one of red, green or blue. Thus, this result may have a small percentage of the result as red, a larger percentage as green, and some intermediate percentage as blue. Thus, in such a result, the predicted value for the unknown cell can be returned as green so that the certainty is proportional to the attempted prediction that returned green from all guesses. Thus, if 100 trials are made to determine the RGB values and 43 of them return green, it can be determined that the certainty of green is 43%. Again, many other examples and interpretations of the returned distribution are possible. In certain situations, the analysis engine simply returns a value or score that represents the confidence or certainty in the results, and in another situation, a distribution that represents the number of attempts made to render the predicted value. .

  According to another embodiment, the method 1721 further displays a user controllable minimum confidence threshold in a graphical user interface (GUI) that displays the tabular data set as output to the user in a spreadsheet or table. Displaying a maximum fill percentage for the GUI, wherein the maximum fill percentage exceeds a minimum user-controllable reliability threshold as a percentage of the sum of all null values and all known values. Corresponds to the sum of all known values and all null values that return a predicted value with.

  According to another embodiment, the method 1721 further receives a confidence measure for each of a plurality of null values in the tabular data set in response to querying the index for predicted values. And displaying the predicted value to the user as an updated output is predicted corresponding to a reliability quality that, when present, exceeds a default minimum confidence threshold or a user-specified minimum confidence threshold. Includes displaying the selected one of the values.

  According to one embodiment, the query is issued for any unknown value, and in response, the predicted value is returned and then ranked or ordered according to its corresponding confidence measure. When the slider is at 100 percent fill per user input, the display is updated to show all cells with either known or predicted values, regardless of confidence in the predicted values. Is done. Conversely, if the user's minimum threshold entry field is set to 100%, only known values will be displayed. Then, dropping the certainty threshold to 75% yields a display output with all known values (which are 100% certain in nature) and any predicted value with a certainty index of at least 75%. It will be rendered. In this way, the user can intuitively operate the controls to search for data and interact with the data.

  According to another embodiment, the method 1721 further receives a distribution for each of a plurality of null values in the tabular data set in response to querying the index for predicted values. Calculating a reliable interval for each received distribution, and displaying the predicted value to the user as an updated output is a prediction corresponding to the calculated reliable interval that exceeds the minimum threshold Display the selected one of the selected values.

  A reliable interval (or Bayesian confidence interval) is an interval in the domain of the posterior probability distribution used for interval estimation. Generalization for multivariate problems is a reliable area. For example, in an attempt to determine the uncertainty distribution of the parameter t, if the probability that t exists between 35 and 45 is 0.95, 35 <= t <= 45 is a 95% reliable interval. .

  According to another embodiment of method 1721, displaying the tabular data set further includes displaying a known value as the first text type in a cell of the spreadsheet, and for each one of the unknown values. Querying the index for a predicted value corresponding to, and displaying the predicted value to the user as an updated output is predicted as the second text type in the spreadsheet cell The second text type has display opacity proportional to the confidence measure for the predicted value displayed.

  According to another embodiment of method 1721, displaying the tabular data set to the user as output includes displaying a known value as black text in a spreadsheet cell and updating the predicted value. Displayed to the user as a rendered output as grayscale text, such that a predicted value with a higher confidence index is displayed in a darker grayscale than a predicted value with a lower confidence index Including displaying the predicted value.

  For example, instead of using a slider, all values may be provided to the user as a display output. For example, a known value may be drawn in pure black text, and then predicted by displaying the predicted value as grayscale text such that its intensity or opacity is proportional to its certainty. Different values may be distinguished. Thus, a predicted value with high confidence can be displayed in dark gray text that is not completely black, whereas a predicted value with low confidence is in light gray text. Can still be displayed.

  According to another embodiment, the method 1721 further includes displaying a predictive difficulty score for every column of the tabular data set displayed as output to the user for each column, the predictive difficulty score being a table. For each column of the formal data set, (i) identify all unknown values in the column and (ii) query the index for predicted values corresponding to each of the unknown values identified in the column. (Iii) receiving a confidence measure for each unknown value identified in the column; and (iv) based on the confidence measure received for the unknown value identified in the column. And calculating a predictive difficulty score for this column.

  According to another embodiment of method 1721, the method further includes displaying a maximum fill percentage for every column of the tabular data set displayed as output to the user for each column, wherein the maximum fill percentage is: Based on the quantity of unknown values identified in each column having a confidence measure that exceeds a minimum confidence quality threshold.

  For example, taking each column in the original tabular data set as an example, how many of the specific columns obey the minimum confidence threshold, while at the same time being predicted values or known values and predicted values. There will be an indication to the user as to whether it can be entered using a combination of Therefore, to achieve 100% fill for a particular column, the minimum confidence may need to be significantly reduced. When certainty is reduced, more of each column can be filled by replacing unknown values with predicted values. One column is likely to be predicted more easily, and therefore it can reach 100% fill for a given certainty while another column at the same certainty remains partially unfilled. Despite this, such a display to the user allows the user to simply and intuitively search for data with minimal learning curves, without a deep technical understanding of the probabilistic method of rendering predicted data values. To do.

  According to one embodiment, there is a non-transitory computer readable storage medium having instructions stored thereon, wherein the instructions are to receive a tabular data set as input from a user when executed by a processor in a host organization. The tabular data set has data values organized as columns and rows, and identifies a plurality of null values in the tabular data set, wherein the null value is tabular data Generating an index from a tabular data set of columns and rows interspersed across a plurality of rows and columns of the set, wherein the index includes the rows and columns of the tabular data set; Representing the probabilistic relationship in and displaying the tabular dataset as output to the user, the displayed output being rendered as a known value. User input to input a predicted value for at least a portion of the unknown values in the displayed tabular data set, including data values to be displayed and null values drawn as unknown values From the host, querying the index for the predicted value, and displaying the predicted value to the user as an updated output to the host organization.

  FIG. 18 depicts feature movement 1801 and entity movement 1802 in an index generated from analysis of a tabular data set. On the left, feature movement 1801 is depicted in three views, view 1 at element 1810, view 2 at element 1811 and view 3 at element 1812. As depicted, feature 1805 (eg, column, property, etc.) is another existing 1820, as is done via the arrow pointing to the left to move feature 1805 from view 2 at element 1811 to view 1 at element 1810. Can be moved to the view, or alternatively, feature 1805 is moved to new view 1821 as is occurring in feature 1805 as depicted by the right-pointing arrow to move feature 1805 to new view 4 in element 1813 be able to.

  On the right side, entity movement 1802 is depicted in two categories, with category 1 at element 1825 and category 2 at element 1826 shown. As depicted, entity 1806 (eg, a row, etc.) may move entity 1806 to another existing 1823 category, as depicted by the downward pointing arrow that moves entity 1806 from category 1 in element 1825 to category 2 in element 1826. Alternatively or alternatively, the entity 1806 can be moved to the new category 1824, as is happening to the entity 1806 as depicted by the longer down arrow to move the entity 1806 to the new category 3 in element 1827.

  FIG. 19A depicts a specialized GUI 1901 that queries using a history date. The specialized GUI 1901 implementation depicted here allows a user to filter on historical values by comparing historical values versus current values in a multi-tenant database system. Filtering historical data is enabled via a GUI “Close date (Historical)” drop-down box or similar means (eg, a calendar selector, etc.), Displays the current field associated with the field.

  GUI 1901 allows a user to filter historical data by comparing historical values versus fixed values in a multi-tenant database system. The GUI 1901 does not require the user of the GUI to understand how API calls are constructed, or even what command terms or parameters need to be specified to produce the appropriate output. To exploit the predictive capabilities of the analysis engine by constructing and issuing appropriate API calls. Thus, GUI 1901 provides the user with a highly intuitive interface without a steep learning curve.

  The GUI 1901 performs the necessary queries or API calls and then consumes the data. The data is presented back to the end user via a GUI 1901 display interface, such as the client device 106A-C shown in FIG. For example, consider an example where a salesperson is looking at sales information in a particular data set. The GUI 1901 interface takes the distribution provided by the analysis engine and can create visual indications that rank information according to various customized solutions and use cases.

  For example, SalesCloud is an industry-leading CRM application currently used by 135,000 enterprise customers. These customers understand the value of storing their data in Cloud, fully understand the web-based GUI 1901 interface, browse their data, and act on their data. These customers frequently make use of the reporting and dashboard mechanisms provided by cloud-based services. Presenting the various GUIs described above as tab-type functionality means that sales people and other end users can explore their underlying data sets in various ways and how their business functions. It is possible to learn in real time. These users can also rely on partners to extend the cloud-based service capabilities provided through additional GUIs that use the APIs and interfaces described herein.

  Cloud-based services that provide customers with the opportunity to learn from the past and create data-driven insights, these functionalities enable these customers to make intelligent decisions about the future of their business based on their existing datasets. It is highly desirable to get help. GUI 1901 provides such an interface.

  The customized GUI takes advantage of the analysis engine's predictive functionality to the customer organization to adapt the GUI's configuration and operation and how the GUI performs API calls to the analysis engine's functionality. Implement reports that depend on forecast results that can be adapted to the needs of a particular customer organization through published programmatic parameters and settings, or that can vary from customer organization to customer organization.

  For example, a GUI 1901 can be provided to calculate and assign an opportunity score for a given opportunity based on the probability reflecting the likelihood of closing as a win or loss of this opportunity. The data set for calculating this score includes all opportunities closed (either win / loss) within a given period, such as 1, 2 or 3 years or the lifetime of the organization. The duration can be configured using the GUI 1901 date range control that specifies the date range, even if the range falls in the past.

  Additional data elements from the customer organization data set may also be utilized, such as an account table as input. Then machine learning techniques implemented through the core of the analysis engine, eg, SVN, Regression, decision tree, PGM, etc. are used to build the appropriate model and render the opportunity score, GUI 1901 Draw information to the end user via the interface.

  FIG. 19B depicts a further view of a specialized GUI 1902 that queries using historical dates. The specialized GUI 1902 implementation depicted here allows the user to determine the likelihood that an opportunity will close using historical trend data. For example, the GUI 1902 allows a user to easily construct a prediction query using a “history” selector that selects a relative or absolute date.

  In this GUI 1902, the user is allowed to see how the opportunity has changed over time, such as independently of the stage. The user can further see how the opportunity has matured from the time it was created until it was closed. For example, the GUI 1902 uses the data structure control to set history data from January 1, 2013 to March 1, 2013, and the table at the bottom shows that the opportunity amount is reduced by $ 10,000. However, it depicts that the stage was a “prospecting” phase and still a prospective phase.

  The GUI 1902 further allows the user to determine the likelihood that an opportunity closes at a given stage using historical trend data. Where the above GUI 1901 operates independently of the sales opportunity stage, the GUI 1902 focuses on the probability of closing at a given stage as a further limiting condition of closure. Thus, the customer can use historical trend data to know exactly when the stage has changed, and then to predict which factors were involved in the transition from stage 1 to stage 2 and stage 2 to 3 etc. Made possible.

  The GUI further allows the user to predict the opportunity to close based on additional social and marketing data provided in the interface or specified by the user. For example, the data set of any customer organization or anyone using the system can be extended for end users beyond the underlying data set by incorporating the social and marketing data described above, Used by the analysis engine to further influence the prediction model and educate the prediction model. For example, certain embodiments derive information from an exemplary website, such as “data.com”, from which the data is an analysis engine that is feasible to discover additional relationships, causal relationships and hidden structures Is associated with each opportunity in the original data set, and then the above relationships, causal relationships and hidden structures can be presented to the end user. Other data sources are equally feasible, for example, pulling data from social networking sites, search engines, data aggregation service providers, etc.

  In one embodiment, social data is retrieved and feedback is provided to the end user via a GUI to depict how a given product is viewed by others in a social context. Thus, the salesperson can see the customer's LinkedIn in the profile, data. Using information from com or other sources, the salesperson can further be given a sentiment analysis in terms of social context about the person he is actually trying to sell. For example, the above data may reveal whether the target buyer is commenting on other products, or perhaps complaining about other products. Each of the above data points can affect the model employed by the analysis engine to help further improve the rendered prediction.

  In another embodiment, determining the likelihood that an opportunity closes is further based on industry specific data retrieved from an external source for the initially specified data set. For example, rather than using socially relevant data for the social context of sentiment analysis, industry specific data can be retrieved and entered into the prediction database. In this prediction database, the analysis engine performs its modeling as described above, and then the user can perform further searches from the prediction database on the dataset that now has industry-specific data integrated into it. .

  According to other embodiments, the data set is searched across the boundaries of any particular customer organization that has data in the multi-tenant database system. For example, in certain embodiments, benchmark prediction scores are generated based on industry-specific learning using cross-organizational data stored in a multi-tenant database system. For example, data mining may be performed on a telecommunications specific customer data set, subject to authorization or license to execute. Then, such cross-organizational data for rendering larger multi-tenant datasets is analyzed through a model of the analysis engine and provides insights, relationships, causal relationships and data that cannot exist within a single customer organization dataset. Additional hidden structures can be provided. For example, if a customer is trying to close a $ 100k deal in a three-city area of NY-NJ-Virginia, the probability that this deal will close after 3 months may be 50%, according to the above analysis. Because when past transactions are viewed in the context of multiple customer organization datasets, it can take up to 6 months to close a $ 100k telecommunications deal in a three-city area of NY-NJ-Virginia. It is because it shows. Many of the insights realized through these processes are non-intuitive, but can be realized through application of the techniques described herein.

  It is possible to explore data more deeply in industry specific data present in a given data set and use these data to identify benchmarks for various variable domains across multiple different industries. For example, based on the above data, the predictive analysis will outline that it will take 6 months to sell sugar in the Midwest and 3 months to sell a laptop on the east coast in a given area. Can do.

  Then, if a new opportunity arises and the vendor is trying to sell a watch in California, for example, the vendor can use the above information to find out about the market in a particular area based on the confidence level and forecast given. A better understanding can be gained.

  FIG. 19C depicts another view of the specialized GUI 1903 that composes the prediction query. The prediction functionality of the analysis engine can further reveal information about the vertical sector and its region. When mining a customer organization data set, if a customer buys item “a”, then a relationship may be discovered in which he / she bought item “b”. This type of matching relationship is useful but can be further strengthened. For example, the analysis engine's predictive analysis can be further used to identify a set of factors that led to a particular opportunity score.

  As depicted here, GUI 1903 presents a 42% opportunity in the user interface, but when the user places the cursor over an opportunity score (eg, a mouse over event), GUI 1903 displays this opportunity score. Display sub-detail with additional elements to build. The GUI 1903 may select and execute an appropriate predictive command term for the index so as to extract to the user an opportunity score and related display information including subordinate details and causality that are considered relevant. Reconstruct and issue the necessary API calls for the user.

  The GUI 1903 further triggers the appropriate function for a given opportunity as specified by the user in the GUI 1903 to return the raw data required by the GUI 1903 to create a histogram of opportunities. Utilize the ANALYZE command term. Thus, not only can the user be given a score, but also how the information should be interpreted to assist the user in determining the appropriate action trigger given the information provided. Related factors and guidance can be given.

  Furthermore, when an end user such as a salesperson examines the data and acts on it, a feedback loop is created in which further data is entered into the prediction database, where further prediction and analysis is an adaptive method. Is executed. For example, when the analysis engine learns further about the data set associated with an exemplary user or salesperson, the underlying model will re-calibrate the data with new data obtained via the feedback loop. It can be refreshed on a circular basis by re-running the set analysis. The new data above explains whether the sales opportunities were closed or lost in sales, identify the final amount, timing, resources involved, etc. to help inform the model better, and in the future Better predictions can be rendered for the query.

  FIG. 19D depicts an example architecture in accordance with the described embodiments. Specifically, customer organizations 1905A, 1905B, and 1905C are depicted, each comprising a user's client device and display 1906A, 1906B, and 1906C, and the user's client device and display 1906A, 1906B, and 1906C are used to enter, query, and Ability to interface with host organization 1910 via network 1925, including sending requests and responsively receiving responses including output for display. There is a request interface 1976 within the host organization 1910, which may optionally be implemented by the web server 1975. The host organization further includes a processor 1981, memory 1982, query interface 1980, analysis engine 1985, and multi-tenant database system 1930. There is execution hardware, software, and logic 1920 in the multi-tenant database system 1930, and the execution hardware, software, and logic 1920 are shared across multiple tenants of the multi-tenant database system 1930, the authenticator 1998, and the prediction database 1950, The prediction database 1950 is capable of storing an index generated by the analysis engine 1985 to facilitate returning a prediction record set in response to a query executed against the prediction database 1950.

  According to one embodiment, the host organization 1910 runs a system 1911 having at least one processor 1981 and memory 1982. The system 1911 is a request interface 1976 that receives input from a user device 1906A-C specifying a sales data dataset 1953 for a customer organization 1905A-C, wherein the sales data specifies a plurality of sales opportunities. A request interface 1976 and an analysis engine 1985 that generates an index 1954 from the rows and columns of the data set 1953, wherein the index represents a stochastic relationship between the rows and columns of the data set 1953; A prediction database 1950 storing 1954, an analysis engine 1985 for selecting one or more of a plurality of sales opportunities specified in the sales data, and winning or losing for each of the selected one or more sales opportunities ( Win / Lose) Prediction A query interface 1980 that queries an index 1954 for 1958 (1957), the query interface 1976 as a display output 1955 to the user device 1906A-C, and a win / loss prediction for each of the selected one or more sales opportunities. The result 1958 is further returned.

  Request interface 1976 can further receive and respond to user event input 1956 from user device 1906A-C indicating one or more of the displayed sales opportunities or their corresponding win-loss prediction results 1958. The user interface can then provide further drilldown sub-details. For example, if a touchscreen user touches one of the displayed opportunities or clicks one of the displayed opportunities, the user interface communicates such input to the request interface 1976 to specify the specified sales opportunity. The host organization can be provided with a display output 1959 that is updated with further details, such as related characteristics.

  According to another embodiment, the system 1911 further includes a prediction database 1950 that stores an index generated by the analysis engine. In such embodiments, the prediction database 1950 is implemented as an on-demand cloud-based service at the host organization 1910 for one or more subscribers.

  In another embodiment, the system 1911 further includes an authenticator 1998 that verifies the user (eg, the user at the user's client device and one of the displays 1906A-C) as a known subscriber. The authenticator 1998 further operates to verify authentication credentials presented by known subscribers.

  In another embodiment, the system 1911 is further a web server 1975 that implements a request interface, and as input, one or more of a plurality of customer organizations that interface with a host organization over a network. A web server 1975 that receives a plurality of access requests from a client device and a multi-tenant database system with predictive database functionality to implement a predictive database, each customer organization being a separate and distinct remote Or an organization group within the host organization, a business partner of the host organization, or an entity selected from the group consisting of customer organizations that subscribe to cloud computing services provided by the host organization.

  FIG. 19E is a flow diagram illustrating a method according to a disclosed embodiment. The method 1921 may be performed by processing logic that includes hardware according to a system, apparatus, and method for rendering an opportunity scored using a predictive query interface as described herein. (Eg, circuit, dedicated logic, programmable logic, microcode, etc.), software (eg, send, send, receive, execute, generate, calculate, store, publish, query, process, etc.) Instructions executed on the device) and the like. For example, the host organization 110 of FIG. 1, the machine 400 of FIG. 4, or the system 1911 of FIG. 19D can implement the described methodology. Some of the blocks and / or operations listed below are optional in certain embodiments. The block numbering presented is for clarity and is not intended to define the order in which the various blocks should occur.

  At block 1991, processing logic receives input from a user device specifying a data set of sales data for a customer organization. The sales data specifies a plurality of sales opportunities.

  At block 1992, processing logic generates an index from the rows and columns of the data set. The index represents a probabilistic relationship between the rows and columns of the data set.

  At block 1993, processing logic stores the index in a queryable database within the host organization.

  At block 1994, processing logic selects one or more of the plurality of sales opportunities specified in the sales data.

  At block 1995, processing logic queries the index for a winning or losing prediction result for each of the selected one or more sales opportunities.

  At block 1996, processing logic displays the winning or losing prediction results for each of the selected one or more sales opportunities as an output to the user device.

  The user interface (UI) or graphical user interface (GUI) consumes the prediction results and data returned from the prediction interface so that the scored sales opportunity, the quality of the prediction, which factor or characteristic is probabilistically The prediction results are displayed to the user in a very intuitive way, along with other data such as other metrics that are relevant or displayed.

  According to another embodiment of the method 1921, querying the index for a winning or losing prediction result for each of the selected one or more sales opportunities may include, for each of the selected one or more sales opportunities, a PREDICT command term. Generating a Predictive Query Language (PreQL) query that specifies, issuing each of the generated PreQL queries to the Predictive Query Language application programming interface (PreQL API), and responding to the issued PreQL query Receiving a winning / losing prediction result for each of the selected one or more sales opportunities.

  According to another embodiment of the method 1921, the data set of sales data includes closed sales opportunities, for which the win / loss results are known and the sales for each closed sales opportunity. Recorded in the data set of data. The sales data dataset further includes an open sales opportunity, for which the win / loss result is unknown and corresponds to a null value in the sales data dataset for each open sales opportunity To do. Each of the plurality of selected sales opportunities is selected from open sales opportunities.

  According to another embodiment of the method 1921, querying the index for win / loss prediction results for each of the selected one or more sales opportunities is constructing a query that specifies the selected sales opportunities. The query specifies a PREDICT command term, includes operands for the PREDICT command term including at least a row corresponding to the selected sales opportunity and a column corresponding to the win / loss result, and issues a constructed query In response to receiving a winning or losing prediction result for a row corresponding to the selected sales opportunity.

  According to another embodiment, the method 1921 further queries the index for predicted sales for each of the selected one or more sales opportunities, and outputs the selected 1 to the user equipment. Or displaying the predicted sales amount together with a winning / losing prediction result for each of the plurality of sales opportunities.

  According to another embodiment of the method 1921, querying the index for predicted sales is to build a query for each of the selected sales opportunities, each query specifying a PREDICT command term. , Including operands for a PREDICT command term including at least a row corresponding to the selected sales opportunity and a column corresponding to the sales volume, and selected in response to issuing the constructed query Receiving predicted sales results for the row corresponding to the sales opportunity.

  Querying the prediction query interface returns the prediction result being sought (eg, win / loss prediction, predicted closing height, predicted closing date, etc.), but more relevant is the quality of this prediction, ie The probability or likelihood that the rendered prediction will be realized. The predictive query interface can return a distribution, interval or other value depending on the structure and composition of the issued query. For example, a confidence quality indicator may be returned that indicates a value between zero and one hundred and provides a quantitative metric for assessing the quality of the prediction.

  Providing predicted win / loss results for existing sales opportunities along with a quality measure for the rendered predictions is useful for salespeople who must assess which sales opportunities should be targeted. Of course, salespeople are encouraged to spend time and resources on opportunities that are more likely to bring success. Thus, the output above helps the salesperson assess which sales opportunities are likely to close, and therefore what might work in the effort to meet the sales quota and maximize their commissions. obtain.

  According to another embodiment, the method 1921 further includes receiving a confidence measure for each of the winning and losing prediction results and displaying the winning and losing prediction results for the selected one or more sales opportunities. Displaying a confidence measure at the output to the device.

  According to another embodiment, the method 1921 is further responsive to the query to receive a confidence measure for each of the selected one or more sales opportunities along with the winning or losing prediction result, and the selected Displaying a winning / losing prediction result for each of the one or more sales opportunities, and simultaneously displaying the received reliability index as an output on the user device.

  Certain embodiments are configured with a benchmark or threshold, such as 70%, or some other default or user-configured to establish the minimum confidence quality required for sales opportunities returned to the user display A value may be used. A second threshold may be required for such an embodiment, which further displays the recommendation on the user display.

  According to another embodiment of the method 1921, selecting one or more of the plurality of sales opportunities includes selecting all sales opportunities in the sales phase prior to closure and having an unknown win / loss result; Identifying one or more of a plurality of sales opportunities that have a winning or losing prediction result that exceeds a minimum reliability index threshold, and displaying the winning or losing prediction result as an output on a user device includes: Including displaying one or more of the sales opportunities as having a winning or losing prediction result that exceeds a minimum confidence index threshold.

  For any given sales opportunity, there can be multiple sales stages, which can be in an open or closed stage (eg, an open state is a pre-closed state or an opportunity Can be at any stage prior to closing). Sales opportunities can be in any of a number of interim stages, particularly for sales teams that buy and sell with large customers and handle large sales transactions. These stages create a sales lifecycle. For example, there may be a discovery stage where the salesperson works to determine what is the right product for a given customer, a pricing or estimation stage where pricing is determined and discounts are negotiated.

  For large transactions, the sales life cycle can last three months, six months, and sometimes nine months, depending largely on the size and complexity of the sales opportunities. Very complex transactions can last for years, such as when a customer is considering a multi-billion dollar commitment, such as for an airplane engine. Smaller, less complex transactions, such as contracts for database software, can move more quickly.

  According to another embodiment, the method 1921 further includes displaying the recommendation as an output on the user device, the recommendation specifying at least one of a plurality of sales opportunities in the sales phase prior to closure. For the output, the recommendation specifies (i) at least one of a plurality of sales opportunities in the sales phase before closing by a sales opportunity name as specified by the sales data dataset. The above recommendation further outputs (ii) a winning / losing prediction result indicating sales win, (iii) a reliability index for the winning / losing prediction result indicating sales win, (iv) a predicted sales volume, and (v ) Designate one or more of the predicted sales opportunity closing dates.

  The closing date may be predicted and provided as an output, which can be very relevant for the purpose of sales forecasting. For example, if a salesman declares to the management that the sale will be closed in accounting Q1, but the forecast returns a highly reliable closing date in accounting Q3, adjust the sales forecast or give It may be appropriate to change the strategy for sales opportunities (eg, increase urgency, improve pricing clauses, discount, etc.).

  The user interface further provides a means for the user to change the default value, specify the relevant historical date range that the forecast and query will be based on, and specify the range of data sets to be used for the forecast. You can specify it.

  For example, a user management page equivalent to that described above in FIGS. 19A, 19B, and 19C provides reporting capabilities through which the user can enter input sources (eg, sales data for customer organizations). Data sets), restrictions, filters, historical data, and other related data sources, such as social media data, updated sales data, and the like.

  According to another embodiment of method 1921, the recommendation is determined based on a weight assigned to the output specified in (i)-(iv), which is assigned by default and displayed at the user equipment. Custom configurable via a graphical user interface (GUI).

  According to another embodiment of the method 1921, selecting one or more of the plurality of sales opportunities is closed with selecting a sales opportunity that is in a closed sales phase and has a known win / loss result. Querying the index for a winning or losing prediction result for each of the selected one or more selected sales opportunities that have a known winning or losing result, the winning or losing prediction result ignoring the known win or lose result, And the prediction accuracy for each of the selected sales opportunities is selected by comparing the known win / loss results against the win / loss prediction results, and the win / loss prediction results are displayed. Displaying the determined prediction accuracy for each of the plurality of sales opportunities as an output on the user device.

  According to another embodiment, the method 1921 further includes receiving a date range input from a GUI displayed on the user device, the date range input specifying a historical date range on which the win-loss prediction results are based.

  According to another embodiment of the method 1921, receiving input from a user device specifying a data set of sales data for a customer organization includes receiving the data set as a table having columns and rows, and data Receiving a data set as a stream; receiving a spreadsheet document; extracting the data set from the spreadsheet document; receiving the data set as a binary file created by the database; Receiving a plurality of queries, receiving the data set in response by executing the one or more queries against a database, and capturing the record set returned by the one or more queries as a data set; Receive the name of the table in the database Retrieve this table as a dataset from the database and receive search parameters for the specified website, query the specified website for the search parameters in response, and capture the search results as a dataset And at least one of receiving a link and authentication credentials for the remote repository, authenticating in response to the remote repository, and retrieving the data set via the link.

  According to another embodiment, the method 1921 further includes receiving an entity selection input from a GUI displayed at the user equipment, the entity selection input being the output of the winning or losing prediction result displayed at the user equipment as an output. Designating one, and in response to an entity selection input, displaying subordinate details for one of the sales opportunities on the user device as an updated output, wherein the subordinate details are displayed One or more features that are stochastically related to the winning or losing prediction results.

  According to another embodiment of the method 1921, the entity selection input is a mouse over event, cursor over event, click event, touch screen selection event, or touch screen position event corresponding to one of the displayed win / loss prediction results. Displaying sub-details including one includes displaying sub-details in a graphical overlay that is positioned over and at least partially covers the initially displayed win-loss prediction results .

  According to another embodiment, the method 1921 further includes constructing a query to retrieve one or more features that are stochastically related to the displayed win-loss prediction result, the query comprising a RELATED command term and And at least one operand for a RELATED command term that specifies a column corresponding to the win / loss result column.

  For example, it may be determined that a sales opportunity sponsor will be probabilistically related to sales wins or losses. Hence, the UI is additionally available, such as senior management who can talk to satisfied customers or potential customers in an effort to increase the likelihood of success for a given sales opportunity. Provide functionality to track sponsors.

  The user interface further constructs and issues a SIMILAR command term for the forecast database to return and display sales opportunities that are the specific sales opportunities assessed by the salesperson most. Such data can help salespeople draw further insights from other similar sales opportunities that have or have not resulted in successful wins.

  By understanding which factors affect specific sales opportunities, sales representatives can influence these factors in an effort to increase the likelihood of successful closure for a specific sales opportunity. It can be specifically focused. For example, if a conversation between a customer and a company CEO proves useful in a particular type of transaction, this can be a valuable resource expense. Conversely, if a given type of pricing structure would be favorable for a particular customer type, product or industry, this is a valuable consideration to increase the likelihood for a given sales opportunity. obtain. The search for properties as described above can be done through the user interface, including manipulating values as “assumed” scenarios and then updating the prediction results for the user display based on “assumed” scenario parameters.

  According to another embodiment of the method 1921, displaying the sub-details includes displaying a column name for one or more features that are stochastically related to the displayed win-loss prediction result; and Displaying data values from the data set corresponding to the row and column intersections for the entity rows corresponding to one sales opportunity for the displayed sub-details.

  Social media data is a type of auxiliary data. Various data sources may be specified to further enhance the prediction results, including, for example, contacts, accounts, account phases, account tasks, account contact persons, account sponsors or referrals.

  Social media data is available from sources including Radian6 and Buddy Media provided by salesforce.com. These sources provide aggregated and structured data that is picked up from social media sources such as Facebook, Twitter, and LinkedIn. With such a source, it may be possible to associate an individual such as “John Doe” with a particular sales opportunity to enhance the index with data associated with John Doe in the social networking space. For example, perhaps John Doe is tweeting about a competitor product or a product offered by a salesperson. Alternatively, there may be a news feed that mentions the product or company or targeted sales opportunity, or there may be a contextually relevant customer review, etc. These data points can be integrated by specifying the appropriate source in the UI, which will in turn cause the analysis engine to perform further analysis to update the index, If stochastically related, the relationship will affect the prediction results and can be discovered through the user interface.

  In certain embodiments, benchmarking capabilities are provided that allow users to analyze supplemental data sources based on, for example, manufacturing versus high-tech industries, data located for each customer in a geographic region, etc. To. Such data is usually not maintained by the customer organization, but can be sourced and specified as additional supplemental data through the user interface, in which the analysis engine core can update the index, and , Improve forecasting results, or generate additional insights into customer organization data that would otherwise not be possible.

  In one embodiment, the supplemental data source described above is provided through the user interface as part of an existing cloud-based subscription or at an additional fee payment. For example, a customer can purchase a data package that can integrate industry benchmarking data to analyze customer organization's specific sales opportunities, for potential sales customer collections or for potential verticals ( potential verticals) can be performed in consideration of aggregated benchmarking data, such as for collections. Once this additional data is specified, analyzed, and its index updated, the user can search for this data and its impact on the prediction results through the provided UI.

  In one embodiment, the range of historical data that is tracked and can be analyzed, viewed or otherwise searched by the user is based on subscription terms. For example, a cloud-based service subscriber may expose the relevant user interface to all customers free of charge, although the scope of data that can be analyzed may be limited to an exemplary three months, while The paying subscriber gets a deeper, more complete data set, perhaps two years worth of historical analysis. Certain embodiments operate on data sets that are explicitly specified by the customer, while other embodiments are based on the system's knowledge of customer data already stored in the host organization, A specific data set may be defaulted for this customer. In particular, conventional databases do not track and publish a historical view of data stored in the database. While most databases allow change logging and rollback, traditional databases do not expose such data to queries. Because this purpose is not intended. Conversely, the user interface described herein allows the user to specify a historical date range, which then searches for how the data has changed over time. Or allows the database to be queried in terms of past dates, resulting in the query results returning data as at the past date rather than as data currently exists. The methodology described herein is a separate object so that database updates can be fully committed, and changes and audit logs can be flushed without losing historical data. Is used.

  According to another embodiment, the method 1921 further receives from the user device further input specifying a social media data source, updating an index based on the specified social media data source, and selecting Display an updated win / loss prediction result for each of the one or more sales opportunities as an output to the user device, along with characteristics derived from the social media data source determined to be associated with the updated win / loss prediction result Including.

  According to another embodiment of the method 1921, the social media data source corresponds to a social media data aggregator that listens to the social media network and provides aggregated social media data as a structured output. .

  According to another embodiment, the method 1921 further includes receiving a user event input from a GUI displayed at the user device, the user event input being one of the winning or losing prediction results displayed at the user device as an output. Designating one or more sub-details for one of the sales opportunities on the user device as an updated output in response to user event input, the sub-details being displayed It includes one or more features that are stochastically related to the win / loss prediction results.

  According to another embodiment of the method 1921, the one or more features that are probabilistically related to the displayed win / loss prediction result are in the updated win / loss prediction result for each of the selected one or more sales opportunities. Contains one or more name = value pairs derived from the affected social media data source that was affected.

  According to another embodiment, there is a non-transitory computer readable storage medium having instructions stored thereon, said instructions being executed by a processor in a host organization, from a user device, a data set of sales data for a customer organization. The sales data specifies a plurality of sales opportunities, and generates an index from the rows and columns of the data set, wherein the index is a row of the data set. Representing a stochastic relationship between and in a column; storing an index in a queryable database in the host organization; selecting one or more of a plurality of sales opportunities specified in the sales data; Querying the index for winning or losing prediction results for each of the selected one or more sales opportunities; Executing and displaying a winning or losing prediction result for each of the selected one or more sales opportunities as an output to a user device, the operations, including the host tissue.

  FIG. 20A depicts a pipeline change report 2001 in accordance with the described embodiment. On the left side, a pipeline change report showing the total amount history 2002 for the snapshot date 2004 is drawn, and on the right side, a pipeline change report showing the history record count 2003 for the snapshot date 2004 is drawn. , Thus presenting the open pipeline for the current month (for example here the month of January 2013) arranged for each sales phase to the user, including the sales phase at the charted historical date doing. For example, the above steps may include perceptual analysis, proposal / price estimation, negotiation / review, and the like.

  Pipeline change report 2001 allows users to view their data in an aggregated form. Each stage can include multiple opportunities, and each can overlap because each of the opportunities can vary according to the amount, according to the stage, and so on. Thus, if the user is looking at the last 4 weeks, an opportunity can vary from $ 500 to $ 1500 and can therefore overlap.

  The cloud computing architecture performs functionality that runs across all data for all tenants. Thus, for any case, lead and opportunity, the database maintains a historical trending data object (HTDO) where all audit data is retained, thus allowing database updates to be committed. At the same time providing the user with sufficient and rich history in the request to indicate the state of any event in the past without corrupting the current state of the data stored for the database tenant it can. Thus, the underlying data must be maintained in its correct state for the current moment, but nevertheless, the user can use the system to indicate the status of a particular opportunity and the data requested is the status of an opportunity last week. Regardless of whether the status is historical, this status can be displayed as it has historically or as this status has changed throughout the past quarter.

  Then, all of the audit data from the historical object for the various categories of data is aggregated into a historical trend data object. A historical trend data object can then be run across multiple tenants to retrieve the necessary audit trails that can recreate any event at any point in the past for reporting, predictive analysis and exploration. Query by historical report type. The historical audit data may be further exposed to the analysis capabilities of the analysis engine (eg, element 185 of FIG. 1) by including this data in the historical data set to provide further predictive capabilities in the historical audit data. . For example, while historical data is known for various sales opportunities, future conditions can be predicted for the same opportunities described above to help the salesperson properly focus their efforts.

  FIG. 20B depicts a waterfall chart using prediction data according to the described embodiments. Opportunity count 2006 defines a vertical axis, and step 2005 defines a horizontal axis from “start” to “end” across steps 1-8. For example, a waterfall chart can draw a snapshot of all currently working opportunities, separated by stages. Opportunity counts vary upward and downward by stage to reflect different opportunity groupings into various defined stages. The waterfall chart can be used to see two points by defining an opportunity between day 1 and day 2, or as shown here through examples. A waterfall chart may be used to group all opportunities into various stages, where every opportunity is mapped according to its current stage, so the user can explore the past and Allows you to understand what the timing was when the opportunity actually came to closure.

  Historical data and audit history stored in historical trend data objects is enabled through snapshots and field history. The historical trend data object can be used to query the desired data. The historical trend data object may be implemented as one table with an index in this table, and any desired data can be extracted from this table. Various specialized GUIs and use cases are populated using opportunity data retrieved from a table of historical trend data objects.

  FIG. 20C depicts the default interface after adding the first history field. Element 2011 depicts the addition of a historical field filter that includes various options, where the options are filtered by historical amount (eg, values greater than $ 1 million) and filtered by field ( For example, an account name equal to Acme), filtering by logic (eg filter 1 AND (filter 2 OR filter 3)), cross-filtering (eg account with or without opportunity), row Limiting (eg, showing only the top 5 accounts by annual revenue) and finally a “help for selection” option.

  This interface allows a user to filter historical data by comparing historical values versus current values stored internally in a multi-tenant system.

  FIG. 20D depicts the default interface for the added custom filter in more detail. Such specialized filtering implementations allow the user to identify how data has changed, such as on a daily, weekly, or monthly basis. Thus, the user can see data related to the user's opportunity as well as the current time, but using this feature, the user can identify the opportunity based on a specified time, such as absolute or relative time So the user can see how the data has changed over time. In this embodiment, time is used as a dimension to provide a decision tree for the customer to pick an absolute date or date range. The customer can select an absolute date such as January 1, 2013 or a relative date such as the first day of this month or the first day of last month.

  As depicted by element 2025, the menu may be populated exclusively with a history field filter, and history color coding may be used. In element 2026, the selection defaults to rolling days from which "Any Selected Historical Date" can be selected. Alternatively, a fixed date may be selected, but this option is folded by default in the depicted interface. Element 2027 describes various operators that the user can select depending on the selected history field type, and element 2028 provides a default monetary value (eg, $$) as a placeholder attribute that can be modified by the user. 1,000,000).

  The depicted custom filter interface allows sales managers or salespeople to see how opportunities have changed, such as today versus the first day of this month or last month. Through a custom filter interface, users can go back in time and think back where they were a week or a month ago, creating a range of dates and which opportunities created between these dates Opportunities can be identified by displaying what has been done.

  For example, a salesperson who wants the above information may have had 10 opportunities, and on February 1, 2013, the salesperson's target buyer showed interest in the quote, Change from prospect to estimate. Conversely, another target buyer wants to buy immediately and changes the stage from quote to sell / billing / close. Thus, the custom filter interface provides a decision tree based on the various dates created and guides the user through the input and selection process by revealing only the appropriate choices and filters for the first selected date. To do. As a result, its functionality can give salespeople a highly intuitive view of all opportunities that are closed in the month of January or February, or within a given range, quarter or year, etc. it can.

  Querying by date forces the user to identify the user's desired date across the decision tree, allowing the user to further select multiple snapshots, and from the above, the finished result set Is determined from February 1, 2013 to February 6, 2013, for example.

  Also enabled is the ability to filter historical data by comparing historical value pair constants in a multi-tenant system, referred to as a historical selector. Based on the type of opportunity or report, the customer has the ability to filter historical data using a custom historical filter. The interface on the left provides the ability for the customer to see all of the filters that the customer can use to limit the values or fields, so the customer can filter the historical column data for any given value. Make it possible to call. In this way, the customer can see all of the open opportunities for a given month, or can filter the data set according to current column data rather than history. Thus, for a given opportunity, the user can enter an amount, stage, closing date, probability, expected category, or other data element in the interface, and then when the salesperson speaks with the target buyer, Are changed from prospects to estimates based on progress made with the target buyer, negotiated, and finally, won / closed or lost. Filtering factors such as the probability of closing and the predicted category will trigger the prediction query to render the prediction, and the prediction is filtered and other comparisons.

  For example, suppose the target buyer is asking to reduce the amount of sales and the salesperson is trying to increase that amount. All of the data including the change amount for the opportunity and the state change for the opportunity is stored in a historical trend data object that provides an audit trail.

  When current data is updated in the current table, past values become inaccessible to the customer. However, the historical trend data object provides a queryable audit trail through which historical values as described above can be retrieved at the request of the interface and its users. According to one embodiment, historical data is processed at a granularity of one day, so sales representatives return in time within a data set with daily granular reporting and how the data has changed over time. Can be viewed. In another embodiment, all changes are tracked and time stamped so that any changes can be revealed at any frequency.

  In addition to clarifying how opportunities have changed for sales representatives over time, the above metrics can be used for other controls, such as receiving hundreds of cases from sales agents and calling It can be useful for service managers operating call centers that need to assess the best means to close. Similarly, campaign managers operating marketing campaigns not only go back to history to see how events have affected the outcome of past opportunities, but also the various leads and undisclosed through marketing efforts. Assess the best way to close in an opportunity.

  FIG. 20E depicts another interface by default for added custom filters. In the “amount” selector here, the “field” mode is selected instead of the value in the previous example depicted in FIG. 20D. Element 2029 indicates that only the current value will appear in the selector when in "field" mode, so the user can actually place the value in the data range limited data set instead of entering the value. Is allowed to choose from the values present in The interface is not limited to “amount”, but rather operates on any column in the data set, allowing filtering by value or by “field” mode, in which the elector is specified List only the values present in one or more fields for a column. For example, by selecting “stage”, the elector assumes that at least one opportunity exists in each of the four exemplary stages for the specified customer history date range, The stage can be drawn. Thus, the user is presented with a very intuitive interface for searching historical data accessible to him.

  In another embodiment, filter elements are provided to the user to narrow or limit the search according to desired criteria such as industry, geography, trade size, product being handled, etc. Thus, the functionality described above helps sales professionals improve sales productivity and streamline business processes.

  According to one embodiment, historical trend data objects are implemented via a historical data schema where historical data is stored in a table, such as the table depicted in Table 1 below:

上記表１において利用されるインデックスには、ｏｒｇａｎｉｚａｔｉｏｎ＿ｉｄ、ｋｅｙ＿ｐｒｅｆｉｘ、ｈｉｓｔｏｒｉｃ＿ｅｎｔｉｔｙ＿ｄａｔａ＿ｉｄを含む。ＰＫには、ｏｒｇａｎｉｚａｔｉｏｎ＿ｉｄ、ｋｅｙ＿ｐｒｅｆｉｘ、ｓｙｓｔｅｍ＿ｍｏｄｓｔａｍｐを含む（例えば、タイムスタンプ、又はタイムスタンプされたレコードなどを提供する）。ユニーク、検索（find）、所与の日付についてのスナップショット、及び親レコードは、ｏｒｇａｎｉｚａｔｉｏｎ＿ｉｄ、ｋｅｙ＿ｐｒｅｆｉｘ、ｐａｒｅｎｔ＿ｉｄ、ｖａｌｉｄ＿ｔｏ、ｖａｌｉｄ＿ｆｒｏｍである。インデックスｏｒｇａｎｉｚａｔｉｏｎ＿ｉｄ、ｋｅｙ＿ｐｒｅｆｉｘ、ｖａｌｉｄ＿ｔｏは、データをクリーンアップするのを容易にする。上記のテーブルは、特定の実施形態によれば、ユーザのストレージ要件に対してさらにカウントされる。例えば、使用が、ユーザごとに予め構成された数のレコードにおいて上限設定されて（capped）もよく、ユーザの組織についての価格設定計画に基づいて改造できてもよい。あるいは、利用可能なスロットが乏しくなるとき、古いスロットがクリーンにされてもよい。履歴データ管理、行限定、及び統計が、場合により利用されてもよい。新しい履歴について、システムは、新しい履歴テーブルのために列ごとに平均２０バイトと６０個の有効列（５０個の有効データ列＋ＰＫ＋監査フィールド）とを仮定してもよく、こうして、行サイズは１３００バイトである。行推定について、システムは、履歴トレンドがエンティティ履歴と類似の使用パターンを有することになると仮定してもよい。顧客の適用可能リソース限定に対して履歴トレンドストレージ使用を請求することによって、ユーザ及び組織は、自身のリソース制約及び価格設定に対して所望の履歴可用性の深度のバランスをとることになる。

The indexes used in Table 1 above include organization_id, key_prefix, and historical_entity_data_id. The PK includes organization_id, key_prefix, and system_modstamp (for example, providing a time stamp or a time stamped record). The unique, find, snapshot for a given date, and parent record are organization_id, key_prefix, parent_id, valid_to, valid_from. The indexes organization_id, key_prefix, and valid_to make it easy to clean up the data. The above table is further counted against the user's storage requirements, according to a particular embodiment. For example, usage may be capped in a preconfigured number of records for each user, and may be modified based on a pricing plan for the user's organization. Alternatively, old slots may be cleaned when available slots become scarce. Historical data management, line limiting, and statistics may be used in some cases. For a new history, the system may assume an average of 20 bytes per column and 60 valid columns (50 valid data columns + PK + audit field) for the new history table, thus the row size is 1300. It is a byte. For row estimation, the system may assume that the historical trend will have a similar usage pattern as the entity history. By charging for historical trend storage usage for customer's applicable resource limitations, users and organizations will balance the desired historical availability depth against their resource constraints and pricing.

  The sampling of production data that reveals the most recent growth in line counts for entity history is approximately 2.5 B (billion) lines / year. Since the historical trend will store a single row for any number of changed fields, an additional factor of 0.78 may be applied. By limiting the total amount of custom historical trend data objects per organization, the expected row count for historical trends will affect the total growth of the pricing structure among all tenants in the database Can be limited to about 1.2 B rows per year in the worst case scenario.

  Historical data can be stored over a default number of years. If 2 years is provided as an initial default, the size of the historical trend table is expected to remain around 2.4B rows. Custom value columns will be handled by a custom index similar to a custom object. In order to prevent unintentional abuse of the system, such as with automated scripts, each organization will have a history line limitation for each object. Such a limitation may be between 1-5 million rows per object, and the above rows cover the storage of current and historical data based on the analyzed usage pattern of production data. Only a few organizations can hit the configurable limit, sometimes with too many objects. Such a limitation can be handled on a case-by-case basis while allowing a reasonable limitation for the overwhelming number of users. Customized tables may be further custom indexed to help various users query performance on historical trend data objects.

  FIG. 20F depicts an example architecture in accordance with the described embodiments. Specifically, customer organizations 2033A, 2033B and 2033C are depicted, each comprising a user's client device and display 2034A, 2034B and 2034C, and the user's client device and display 2034A, 2034B and 2034C includes input, query and There is the ability to interface with the host organization 2010 via the network 2032, including sending a request and responsively receiving a response that includes an output for display. There is a request interface 2076 within the host organization 2010, which may optionally be implemented by the web server 2075. The host organization further includes a processor 2081, memory 2082, query interface 2080, analysis engine 2085, and multi-tenant database system 2030. The multi-tenant database system 2030 includes execution hardware, software, and logic 2020. The execution hardware, software, and logic 2020 are shared across a plurality of tenants of the multi-tenant database system 2030, the authenticator 2098, and the database 2050. 2050 includes, for example, a database that stores records, such as a relational database, a database that stores historical values, such as an object database capable of hosting historical trend data objects, and an index 2054 generated by the analysis engine 2085. A prediction database capable of storing, wherein the index is predicted in response to a query executed against the prediction database To facilitate return a code set, the prediction database may include.

  According to one embodiment, the host organization 2010 runs a system 2035 having at least one processor 2081 and memory 2082. System 2035 includes a database 2050 that stores record 2060, and updates to record 2060 maintain a historical value for the record as record 2060 is updated in database 2050. 2061 is recorded. According to one such embodiment, the system 2035 further includes a request interface 2076. Request interface 2076 receives input 2053 from user device 2034A-C specifying data to be displayed on user device 2034A-C, and request interface 2076 receives history filter input 2056 from user device 2034A-C. Receive. In one such embodiment, the system 2035 further includes a query interface 2080. The query interface 2080 queries (2057) the record 2060 stored in the database 2050 for the data 2058 to be displayed, and the query interface 2080 determines the historical trend data object for the historical value 2062 of the data 2058 to be displayed. An inquiry is made to 2061 (2057). The system 2035 further includes an analysis engine 2085 that compares the data to be displayed with a historical value of the data to be displayed and that has one or more changes corresponding to the data to be displayed. The value 2063 is determined. The request interface 2076 of the system 2035 then displays at least the data 2058 to be displayed based on the one or more changed values 2063 determined through the above comparison as the display output 2055 for the user devices 2034A-C. And an indication of the changed value.

  The request interface 2076 can further receive a selection input 2065 via a change value indication GUI at the user equipment 2034A-C, wherein the selection input 2065 requests further sub-details for one or more changed values. In response, request interface 2076 and / or web server 2075 can then provide further drill-down details. For example, if a touch screen user touches or gestures one of the indicated changed values, the user interface communicates such input to the request interface 2076 for the specified changed value. The host organization 2010 can be provided with an updated display output 2059 with further details (eg, current and past status, differences, direction of change, predictive win / loss result changes for sales opportunities, etc.).

  According to another embodiment of system 2035, database 2050 is implemented for one or more subscribers at host organization 2010 as an on-demand cloud-based service. The system further includes an authenticator 2098 that verifies the user as a known subscriber and further verifies the authentication credentials presented by the known subscriber.

  According to another embodiment of the system 2035, the web server 2075 interacts with the change value indication GUI that implements the request interface 2076 and that is displayed on the user device 2034A-C by the request interface 2076 and / or the web server 2075. In one such embodiment, the web server 2075 receives as input multiple access requests from one or more client devices in multiple customer organizations that interface with the host organization via the network 2032.

  The system 2035 further includes a multi-tenant database system with predictive database functionality that implements the predictive database. In addition, each customer organization is a separate and distinct remote organization, a group of organizations within the host organization, a business partner of the host organization, or a group of customer organizations that subscribe to cloud computing services provided by the host organization. Is an entity selected from

  FIG. 20G is a flow diagram illustrating a method according to a disclosed embodiment. The method 2031 may be performed by processing logic that includes hardware according to a system, apparatus, and method for performing change value indication and historical value comparison as described herein (eg, Circuit, dedicated logic, programmable logic, microcode, etc.), software (eg, send, send, receive, execute, generate, calculate, store, publish, query, process, etc. on the processing device to perform various operations Instructions to be executed) and the like. For example, the host organization 110 of FIG. 1, the machine 400 of FIG. 4, or the system 2035 of FIG. 20F may implement the described methodology. Some of the blocks and / or operations listed below are optional in certain embodiments. The block numbering presented is for clarity and is not intended to define the order in which the various blocks should occur.

  At block 2091, processing logic stores the record in the database. Updates to a record are recorded in a historical trend data object so as to maintain historical values for the record as the record is updated in the database.

  At block 2092, processing logic receives input from the user device specifying data to be displayed on the user device.

  At block 2093, processing logic receives a history filter input from a user device.

  At block 2094, processing logic queries records stored in the database for data to be displayed.

  At block 2095, processing logic queries the historical trend data object for historical values for the data to be displayed.

  At block 2096, processing logic compares the data to be displayed with the historical value of the data to be displayed to determine one or more changed values corresponding to the data to be displayed.

  At block 2097, processing logic displays a changed value indication GUI that displays at least the data to be displayed and the indication of the changed value based on the one or more changed values determined via the comparison. Is displayed on the user device.

  User interface (UI) or graphical user interface (GUI) and change value indication GUI specifically consume data stored in the database, consume historical data stored in the historical trend data object, and predict Consume the prediction results returned from the interface and display the results to the user in a very intuitive way.

  The problem with conventional database interfaces is that the interface shows the data stored in the database in its current state. This is, of course, the purpose of a database that stores records. Nevertheless, it has a view of the data as it was at some historical date in the past, or the data is between two historical dates, or the past status and data at a specific historical date is today It is sometimes useful to have a view of how it has changed between the current state as it exists.

  Restoring data in the database to a previous state is not a successful solution because it overwrites data in the current state with data in the past that is in error. Thus, the modified value indication GUI provides an intuitive means for the user to search his data as it existed in the past state. This capability allows the user to return in time without corrupting the latest data stored in the database in its current state, and the data specifies data such as the current state of sales opportunities or other such records. Allows browsing as it existed on

  Furthermore, the described methodology eliminates the need for users to write complex code to define complex data schemas or track historical data. For example, it is not necessary to involve IT support in publishing the necessary data or employ programmers to write software customized to track the above information. Instead, the host organization operating as a cloud-based service provides the necessary functionality to the user and publishes it through an intuitive UI such as the described change value indication GUI.

  Furthermore, the user is not required to construct an intricate SQL query, but rather can search and view historical data records and values through the GUI interface. When the modified value indication GUI is combined with the prediction query, the GUI builds the necessary PreQL query for the user and publishes the prediction results to the GUI, thus further extending the data search capability for the user.

  According to another embodiment of the method 2031, the record stored in the database maintains the current state for the data, and the historical value for the record recorded in the historical trend data object is the current state of the data. Maintain one or more past states for the data without breaking it.

  According to another embodiment of method 2031, storing the record in the database includes storing one or more tables in the database, each of the one or more tables being listed in the table. A plurality of columns that establish the characteristics of the entity and a plurality of entity rows recorded in the table as records. Updates to records can be any one of (i) modifying any field at the intersection of multiple columns and multiple entity rows, and (ii) adding or deleting records in the database. Including one.

  According to another embodiment of the method 2031, the update to the record includes receiving an update to the record stored in the database and using the current state data for the record stored in the database as past state data as a historical trend. Recording to the data object, modifying the current state data of the records in the database according to the received update, committing the update to the database, and past state data to the historical trend data object Committing to.

  According to another embodiment of method 2031, historical values for records maintained in historical trend data objects are time stamped. Multiple updates to a single record stored in the database are kept distinct in the historical trend data object and differentiated based at least on a timestamp. In certain embodiments, every update to a record in the database is stored as a new row in the historical trend data object.

  Thus, the host organization's computing hardware stores any changes that occur in the database record as raw data for the user in the historical trend data object. When the user is involved in the GUI interface, an appropriate query is built for the user to query and retrieve the necessary information, display the changed values, display the differences in values, and for a given field Display changes over time, etc. For example, the user can specify two time points, such as today and last month. From this, the necessary functions are built by the functionality of the GUI or web server, the result is queried, the change value is indicated and displayed to the user via the GUI. This display includes highlighting the calculated difference or corrected value to highlight changes in the determined value.

  For example, the change value indication GUI may display undesired changes as red text, using a red directional arrow, or using a red highlight. These undesired changes include a reduction in sales opportunity amount, a reduction in the probability of winning the prediction | a reduction in the probability of losing results (eg, the prediction result for the IS_WON field has a null value), an increase in the predicted sales opportunity closing date, etc. It can be. Desirable changes may be displayed with green text, arrows, or highlights, and neutral changes may simply use gray or black text, arrows, or highlights. Colors different from those described may be substituted.

  According to another embodiment of the method 2031, the changed value indication includes colored or highlighted text displayed on the changed value indication GUI for one or more changed values, and one or more A directional arrow displayed on the modified value indication GUI for the modified value, the direction arrow indicating the presence or direction of the modification, the data to be displayed and the calculated one or more modified values. And at least one of a current state and a past state displayed simultaneously for the data to be displayed based on the one or more changed values.

  According to another embodiment of the method 2031, displaying the modified value indication GUI on the user device is determined via the above comparison with the data to be displayed in addition to the modified value indication. Including displaying both one or more changed values.

  According to another embodiment of the method 2031, the data to be displayed includes a plurality of sales opportunities stored as records in a database, and displaying the change value indication GUI on the user device is a plurality of sales. Including displaying a plurality of sales opportunities on the user device along with an indication of the changed values that draw changes to one or more of the opportunities in the current state versus the past state.

  According to another embodiment, the method 2031 further includes determining a first win / loss prediction result for each of the sales opportunities in the current state and a second win / loss prediction for each of the sales opportunities in the past state. Determining a result and drawing any change between the first win-loss prediction result and the second win-loss prediction result via a GUI pointing to the changed value.

  According to another embodiment of the method 2031, determining the first and second win / loss prediction results includes constructing a prediction query that specifies a PREDICT command term and via a prediction query language (PreQL) interface. Issuing a prediction query against the prediction database.

  According to another embodiment of the method 2031, the changed value indication GUI draws a graph or chart of one or more changed values over time based on the historical value of the data to be displayed.

  The change value indication GUI allows the user to customize the report through a variety of filters, including both normal and historical filters that filter the results of current state data stored in the database. Utilizing the GUI, the user adds a new filter for the report, eg, a history field filter is a logical comparator (eg, equal to, less than, greater than, true, false, null, , Etc.). The user can further specify a history date for use in filtering. For example, results as they existed at a given history date may be requested. Alternatively, two dates may be specified, which will produce a modified value between the two dates, both of which are historical dates, or the current date (eg, today) Can be a history date compared to For example, date ranges are sometimes appropriate to show how sales have changed over time, such as monthly, weekly or daily.

  According to another embodiment of the method 2031, the history filter input includes a history date, a history date range, a history closing date for the closed sales opportunity, and a value or string recorded in the history trend data object. , A field or record present in the historical trend data object, a logical operand or comparator for the value or string recorded in the historical trend data object, and a prediction result threshold or range for the null value present in the historical trend data object And at least one of them.

  According to another embodiment of method 2031, displaying the changed value indication GUI on the user device further displays all changed values for the data to be displayed that can be determined from the historical trend data object. Display all changed values within the data range specified via the history filter input and daily, weekly, monthly or quarterly as specified via the modified value indication GUI Displaying a graph of one or a plurality of changed values in the change section.

  According to another embodiment of the method 2031, historical trend data objects that maintain historical values are active by default as part of the cloud computing service and are exposed to the user via the change value indication GUI.

  According to another embodiment of method 2031, historical trend data objects are limited to historical capacity established based on subscriber fees paid by the user to access the cloud computing service. This historical capacity increases in proportion to the subscriber fee paid by the user, with zero subscriber fee users having access to the minimum default historical capacity.

  Such a model encourages users to maintain their existing data in the cloud at the host organization. This is because users can benefit from the enhanced capabilities not provided by traditional solutions. Even if the user does not pay an additional fee, the user is still exposed to the above capabilities in a limited way, and can later decide whether he wants to expand his historical data search and retention capabilities. .

  According to another embodiment, the method 2031 further includes displaying further sub-details for the one or more changed values in response to the selection input received in the changed value indication GUI. The selection input includes one of a mouse over event, a cursor over event, a click event, a touch screen selection event, or a touch screen position event corresponding to the change value indication to be displayed. Displaying sub-details in a graphical overlay positioned over and at least partially covering the indicated change value indication.

  For example, returning the display output to the user display, the user can further search for results by clicking, gesturing, pushing, or pointing at the item. This triggers the change value indication GUI to render further results that are contextually relevant to the user's action without requiring the user to construct alternative or additional filtering.

  According to another embodiment of the method 2031, the one or more modified values are (i) a win / loss prediction that indicates whether the sales opportunity is predicted to win probabilistically or lose. At least one of a change in the result, (ii) a change in the confidence index for the win / loss prediction result, (iii) a change in the predicted sales volume, and (iv) a change in the predicted sales opportunity closing date. Corresponding to one. Further, lower details corresponding to any one of (i) to (iv) above are displayed on the user apparatus via the change value indication GUI in response to a selection input received in the change value indication GUI. .

  The ability to compare historical results enables pipeline comparison (see, for example, pipeline change report 2001 in FIG. 20A). These reports show how products, sales opportunities or other unchanging business flows have changed over time, for example, how the business pipeline looks today vs. yesterday, or today vs. the previous quarter, or , Allowing users to explore what the business pipeline looked like at the end of the previous quarter versus the end of the same quarter of the previous year. These reports can include sales phases, sales by product, forecasts, categories, forecast results for values still being observed, volume, revenue, and data recorded in the database or forecasted through the forecast database. Charted sales opportunities for any other business metric that can be drawn.

  According to another embodiment of the method 2031, displaying the change value indication GUI to the user is based on a history value maintained in the history trend data object, and the history date specified via the change value indication GUI. A first pipeline chart defined by a quantity of sales opportunities on the first axis for a plurality of available sales phases for sales opportunities on the second axis at a user device. And displaying the second pipeline chart at the same time as the first pipeline chart, wherein the second pipeline chart displays the second history as specified through the change value indication GUI. Drawing the quantity of sales opportunities for a plurality of available sales stages on a date or current date.

  According to another embodiment of the method 2031, the change value indication GUI further displays a recommended prediction adjustment based on a predictive analysis of historical values maintained in the historical trend data object by the analysis engine.

  According to another embodiment of the method 2031, the change value indication draws one or more changed values using red text or highlights, green text or highlights, and gray text or highlights. . The red text or highlight above represents a negative change in the current state versus past state determined via comparison, and the green text or highlight represents the current state determined via comparison Gray text or highlights represent a neutral change in the current state versus the past state as determined through comparison.

  According to another embodiment, there is a non-transitory computer readable storage medium having instructions stored thereon, wherein the instructions are stored in a database when executed by a processor in a host organization, An update is recorded in the historical trend data object to maintain historical values for the record when the record is updated in the database, and the data to be displayed on the user device from the user device. Receiving a specified input, receiving a history filter input from a user device, querying a record stored in the database for data to be displayed, and history for a history value of the data to be displayed Query the trend data object and display it Comparing the data and the historical value of the data to be displayed to determine one or more modified values corresponding to the data to be displayed, and one or more determined through the comparison Based on the changed value, the host organization is caused to perform an operation including displaying a change value indication GUI that displays at least data to be displayed and an indication of the changed value on the user device.

  FIG. 21A provides a chart depicting predicted integrity vs. accuracy. The accuracy / reliability is shown on the vertical axis in element 2105, which accuracy / reliability is below “1.0”, which represents essentially perfect accuracy or the highest possible reliability in the prediction. However, this specific scale reaches “0.4”, which represents somewhat poor accuracy or low reliability. On the horizontal axis, element 2106 depicts the filler percentage, which will use the predicted result when all available elements are needed, starting from “0.0”, meaning no predictive fill. It reaches “1.0” which means that it is buried. Thus, at 0.0, there is no predicted result, and as such, accuracy is perfect because there is only known (eg, actually observed) data. Conversely, at 1.0 fill percentage, any null value present in the data set is filled with the predicted value, but the accuracy / reliability reaches a low between 0.4 and 0.5. As such, the prediction results are less reliable.

  Although any number of different intersections can be drawn, element 2107 depicts the intersection of a precision / reliability of 0.8 on the vertical axis and a fill percentage greater than 50% on the horizontal axis. Are translated as sales forecasts are 80% accurate / confident for more than 50% of the opportunities analyzed by the core of the predictive analytics engine.

  While various data sets can change these exact values, the chart depicts what is commonly found within the rich data sets belonging to such sales data. Specifically, the majority of opportunities can be predicted with a relatively high degree of accuracy / confidence, which in turn is likely to produce the most positive results, according to the predictive analysis performed by the salesperson. Allows you to focus your efforts on an occasion.

  FIG. 21B provides a chart depicting opportunity reliability breakdown. Element 2011 on the vertical axis depicts the number of opportunities ranging from 0 to 9000 in this specific chart, and element 2012 on the horizontal axis ranges from 0.0 confidence to 1.0 confidence. It represents the probability of sales. In particular, rows that go to the left and, likewise, rows that go to the right are very significant. The probability of “0.0” does not correlate to complete the lack of confidence, but rather, as depicted by element 2013 highlighting sales opportunities ranging from 0.0 to 0.2, Correlate with a very high degree of confidence that it is unlikely to bring any sales. On the other side of the spectrum, element 2014 highlights sales opportunities that range from 0.8 to 1.0, as it is likely to close significantly in sales.

  FIG. 21C provides a chart depicting opportunity win predictions. In signal detection theory, the receiver operating characteristic (ROC), or simply the ROC curve, is a graphical plot that illustrates the performance of a binomial classifier system when its discriminatory threshold is changed. This ROC is created by plotting the true positive percentage of positives (TPR = true positive rate) vs the false negative percentage of negatives (FPR = false negative rate) at various threshold settings. . TPR is also known as sensitivity (and, in some areas, called recall), and FPR is 1 minus specificity or true negative rate. In general, if both probability distributions for detection and false alarms are known, the ROC curve is a cumulative distribution function of detection probabilities on the y-axis (with a cumulative distribution function for false alarm probabilities on the x-axis ( -An area under a probability distribution from infinity to + infinity) can be generated.

  The ROC10k curve depicted here maps the true positive rate to the vertical axis ranging from 0.0 to 1.0 confidence marked by element 2021, and further from 0.0 marked by element 2022. The false positive rate is mapped to a horizontal axis spanning a confidence of 1.0, yielding an ROC curve with an area of 0.93.

  FIG. 22A provides a chart that depicts the predictive relationship for opportunity scoring. Predictive currency is conditional on the “IS WON = true | false” field. Element 2206 on the vertical axis depicts “IS WON” as true or false for each source, and element 2207 on the horizontal axis, from left to right, website, Sales AE, etc., EBR generation, sales generation Draw various sales lead sources, including Partner Introduction, AE / Sales, Internet Search-Paid, Inbound Call, and finally AE Generation-Account Creation on the right.

  The interface depicted here is generated for users using historical data sets that have been subjected to predictive analytics to help salespeople or sales teams decide where to apply limited resources. be able to. The chart is subject to interpretation, but certain facts are revealed by analysis. For example, element 2213 indicates that the EBR-generated lead is likely to win sales, element 2212 depicts that AE / sales are not likely to win sales, and in element 2211 As you can see, inbound calls offer about 50/50 chances to win sales. Thus, such data presented in an interface showing predictive relationships for opportunity scoring can help the sales team decide where to focus resources.

  FIG. 22B provides another chart that depicts the predictive relationship for opportunity scoring. Here, the opportunity is conditional on the “IS WON = true | false” field. Elements 2221 on the vertical axis depict “IS WON” as true or false for each type, elements 2222 on the horizontal axis from left to right, add-on business, new business, public, renewal, and right Draws various sales lead types including contracts.

  Element 2223 depicts that the add-on business is more likely to win sales, and element 2224 indicates that the new business is less likely to win sales. As previously mentioned, the interface depicted here is generated for the user using historical data sets that have been subjected to predictive analysis, allowing salespeople or sales teams to decide where to apply limited resources. Can help.

  Additional functionality enables specialized UI interfaces to render the likelihood of renewing an existing opportunity by providing a retention score or probability for an existing opportunity by providing a retention score To do. The above functionality is useful to sales professionals because these metrics can affect where salespeople's time and resources are best spent to maximize revenue.

  Opportunity scoring may utilize a RELATED command term to issue a latent structure query request for an index generated by analysis engine predictive analysis on the data set. For example, the RELATED command term can be used to identify which fields are predictably related to other fields, for example, which fields are related to an “IS WON” field that has a true or false value. It may be used by a structured UI. In addition, other less intuitive fields may be related probabilistically. For example, the lead source field may be determined to be related to a particular column in the data set, while other columns, such as financial quarters, may prove to be less related to win / loss outcomes There is sex.

  FIG. 22C provides another chart depicting predictive relationships for opportunity scoring. Here, the predicted currency is conditional on the “IS WON = true | false” field. Element 2231 on the vertical axis depicts “IS WON” as true or false for each currency, and element 2232 on the horizontal axis, from left to right, US dollar (USD), Australian dollar (AUD), Japan Different sales leads are drawn for each currency, including the yen (JPY), British pound (GBP), Canadian dollar (CAD), and finally the euro (EUR) on the right.

  Interpreting the data, at element 2236, the opportunity is more likely to lead to sales in Japan, and at element 2237, the opportunity is less likely to win in European countries that use the euro. A great deal of data exists for USD-based sales opportunities, while there is not a clear relationship to win / loss by currency, however, the slightly more sales that have been generated will win or lose. Predicted to bring. As previously mentioned, the interface depicted here is generated for a user using historical data sets that have been subjected to predictive analysis to help salespeople or sales teams determine where to apply limited resources. Can help.

  The high-level use cases for such history-based data in a data set that is analyzed and subjected to predictive analysis are not limited to explicitly drawn examples. For example, other use cases may include determining a buying preference and scoring / ranking leads for sales representatives and marketing users. For example, a sales user often gets leads from multiple sources (marketing, external, sales prospects, etc.), often in any given quarter, the sales user is more than the time available to him , Have leads to follow up. Sales representatives often require guidance at key questions, which key questions, for example, which leads have the highest propensity to buy, what is the likelihood of sales, are converted into opportunities If there is a potential sales impact, and if this lead is converted to an opportunity, what is the estimated sales cycle based on historical observations? Find a potential sales lead in the sales territory. And what is the score / rank for each lead in the pipeline so that it can be prioritized.

  The sales agent will determine the top 10 products each account may purchase based on predictive analysis, the size of the transaction when they close successfully, the length of the transaction cycle based on historical trends of similar accounts, etc. You may be asked to decide. When resellers act on these recommendations, they can expand their pipeline and increase their chances to meet or exceed quotas, thus increasing sales productivity, business processes, prospects, and Lead qualification can be improved. Historical data provided and subject to predictive analysis can produce better prediction results, which can be obtained through data exploration using various filters or provided specialized UI charts and interfaces And each of the above can handle the necessary history and prediction queries against the prediction database index for the user.

  Additional use cases for the above history-based data may further include likelihood of closing / winning and opportunity scoring. For example, sales agents and sales managers often have a great deal of buying and selling in their current pipeline and have to manage where their time and attention should be applied in any month / quarter When you can benefit from the above data. As these sales professionals approach the end of the sales period, the pressure to meet their quota is quite important. Opportunity scoring can help rank sales opportunities in the pipeline based on the probability of such trades closing, thus improving the overall efficiency of sales professionals.

  Further data may be exposed to predictive analysis along with historical sales data. Additional data sources include, for example, comments, logged sales activities, standard number of fields for activities (eg, events, call logs, tasks, etc.), C-level customer contacts, decision maker contacts, closed Date, the number of standard fields for the number of times the closing date was pressed, opportunity competitors, standard field opportunities, competitive evaluation, executive sponsorship, standard field sales team vs. custom field sales team and members of each team involved It may include chatter feed and social network data about individuals, executive sponsors involved in trading, DSR (Deal Support Request), and other custom fields.

  History-based data may be useful for the predictive ability of analysis engines to generate metrics such as Next Likelihood Purchase (NLP) and opportunity gaps for sales agents and sales managers. For example, a sales agent or sales manager who is responsible for achieving the quarterly sales target, which type of customer is buying which product, which is most similar to an existing customer, the correct product is correct You will be undoubtedly interested in what is being offered to the customer at the right price and what we can sell further to the customer to increase the trading size. Analyzing historical data on opportunities with similar customers you know you have purchased can reveal sales trends, and using these metrics is about which customers are likely to buy next Generate valuable insights to make predictions, thus improving sales productivity and business processes.

  Another capability offered to end users is to provide customer references for sales professionals and other interested parties. When a sales professional needs a customer reference for a potential new business lead, the above information can be obtained from CRM sources, such as reference data captured in a custom application, intranet site, or database. Often, considerable time is spent searching and stitching together. However, the use case GUI associated with the core of the analysis engine can provide key information to such sales professionals. For example, an application can provide data grouped according to industry, terrain, size, similar product footprint, etc., and which reference assets, such as customer success stories, videos, best practices, etc. Grouped according to the contact person's role, eg CIO, sales VP, etc., available for customer reference, which reference customer can be used to speak to potential buyers Customer reference information, which reference customer has been used many times and therefore may not be a good candidate reference at this time, who at any point in the current or past time, Who are account representatives, who are available internally to the organization to reach or contact the reference customer, It is possible to provide a. This type of information is usually present in database systems, but is not organized in a convenient way, resulting in an overly labor intensive process of retrieving the required referrals. However, the core of the analysis engine identifies the above relationships and hidden structures in the data, which are then made by the specialized GUI interface by calling the GROUP command term, eg via the GUI functionality. Can be retrieved and displayed for the end user. In addition, the functionality identifies the most ideal or best possible reference customer from among many based on predictive analysis and details the use of the proposed reference customer to scored opportunities / It can be incorporated into the closing probability chart. Such data is not totally available from conventional systems.

  According to another embodiment, functionality is provided for predicting forecast adjustments for sales professionals. For example, businesses typically have sales forecasting systems as part of their critical management strategy. However, these predictions are inaccurate due to their nature. It is difficult to know in which direction these expectations are wrong and turn that understanding into an improved picture of what the business is doing. The analysis engine's predictive analysis can improve the above predictions using existing data of the customer organization including existing prediction data. For example, analyzing past forecast data in conjunction with historical sales data can help the business show trends and improve existing forecasts into the future that need to be realized. Sales managers are often asked to provide their respective sales representatives with their decisions or adjustments to forecast data. These activities require that the sales managers aggregate the individual expectations of their respective sales agents, which is a very labor intensive process and tends to introduce errors. Sales managers are familiar with buying and selling their agents and spend time scrutinizing them regularly as part of the pipeline assessment. Improved forecast results help these managers improve the quality and accuracy of their judgment and assessment of current forecast data and are often performed manually or with poor tools such as spreadsheets. Can help automate aggregation functions.

  In one such embodiment, the analytics engine is responsible for sales agents for certain past time spans, for example, for the last eight quarters or other time periods appropriate for other business, for relationships such as forecast versus quota versus actual and causal relationships. Mining past expected trends. The analysis engine's prediction functionality or specialized UI interface is used to provide recommended decisions and / or adjustments that can be applied to the current prediction. By leveraging analytical assessments at various levels of the forecast hierarchy, organizations can reduce the variance between the defined sales quotas, forecasts and performance of individual sales representatives over a period of time, Through improved forecast accuracy, the delta between forecasts and realized sales can be narrowed.

  Although the subject matter disclosed herein has been described by way of example in terms of particular embodiments, it is understood that the claimed embodiments are not limited to the explicitly listed embodiments disclosed. It should be. On the contrary, the present disclosure is intended to cover various modifications and similar arrangements that will be apparent to those skilled in the art. Thus, the scope of the following claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements. It should be understood that the above description is illustrative rather than limiting. Many other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. Accordingly, the scope of disclosed subject matter should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims (20)

A method in the host organization,
Generating an index from a data set of columns and rows, wherein the index represents a stochastic relationship between the rows and columns of the data set;
Storing the index in a database of the host organization;
Publishing the database of the host organization via a request interface;
In the request interface, at least (i) a PREDICT command term; (ii) one or more specified columns to be predicted; and (iii) a column name to be fixed and a value for fixing the column name. Receiving a query for the database specifying one or more column name = value pairs specifying
Using the index stored in the database to generate a representation of a simultaneous conditional distribution of the one or more specified columns to be predicted fixed according to the column name = value pairs. Querying the database using a command term passing the one or more specified columns to be predicted and the one or more column name = value pairs;
Including methods. Responsive to the querying step, generating a predictive record set comprising:
The prediction record set includes a plurality of elements therein, each of the elements specifying a value for each of the one or more specified columns to be predicted;
Returning the predicted record set in response to the query;
The method of claim 1 further comprising:   Publishing the database of the host organization includes exposing a Predictive Query Language Application Programming Interface (PreQL API) directly to the authenticated user, the PreQL API being public to the authenticated user. The method of claim 1, wherein the method is accessible via the Internet. Querying the database using the PREDICT command term includes passing a PreQL query to the database, the PreQL query comprising:
The PREDICT command term as a necessary term;
The required TARGET terms that specify the one or more specified columns to be predicted;
The required WHERE term that designates the column name to be fixed and the value for fixing the column name as the one or more column name = value pairs, and the required WHERE term is specified A required WHERE that restricts the output of the query to a predictive record set that returns elements that are stochastically related to the one or more columns to be fixed and the corresponding values to fix the columns Terms,
An optional FROM term that specifies one or more tables, data sets, data sources and / or indexes to be queried when the optional FROM term is specified;
The method of claim 3 having a query syntax of A method in the host organization,
Generating an index from a data set of columns and rows, wherein the index represents a stochastic relationship between the rows and columns of the data set;
Storing the index in a database of the host organization;
Publishing the database of the host organization via a request interface;
Receiving at the request interface a query to the database specifying a RELATED command term and a column specified as a parameter of the RELATED command term;
Querying the database to pass the specified column using the RELATED command term to generate a predictive record set;
Returning the predicted record set in response to the query, wherein the predicted record set has a plurality of elements therein, each of the returned elements being passed in the RELATED command term A column identifier for the specified column and a confidence index, wherein the confidence index is a potential between the specified column passed in the RELATED command and the column identifier returned for each of the elements. A step indicating whether a relationship exists; and
Including methods.   The associated column included in each element returned in the predicted record set is further in proportion to the number of times that the associated column occurs in the same column grouping as the specified column passed in the RELATED command term. 6. The method of claim 5, based on. Publishing the database of the host organization includes exposing a Predictive Query Language Application Programming Interface (PreQL API) directly to the authenticated user, the PreQL API being public to the authenticated user. Accessible via the Internet,
Querying the database using the RELATED command term includes passing a PreQL query to the database, the PreQL query comprising:
The RELATED command term as a required term;
An optional FROM term that, when specified, specifies one or more tables, data sets, data sources, and / or indexes to be queried, wherein the optional FROM term An optional FROM term in which default values are used for the one or more tables, data sets, data sources and / or indexes to be queried when not specified;
A TARGET term that specifies a sequence to be passed in the RELATED command term;
An optional CONFIDENCE term that, when provided, specifies the minimum acceptable confidence measure to be returned in the predicted record set;
An optional COUNT term that, when provided, specifies the maximum quantity of elements to be returned in the forecast record set;
When provided, an optional ORDER BY that specifies whether the elements of the prediction record set should be returned in ascending or descending order according to a confidence measure for each element returned in the prediction record set Terms,
Has the query syntax of
The method of claim 5. A method in the host organization,
Generating an index from a data set of columns and rows, wherein the index represents a stochastic relationship between the rows and columns of the data set;
Storing the index in a database of the host organization;
Publishing the database of the host organization via a request interface;
Receiving, at the request interface, a query to the database that specifies a SIMILAR command term, a row specified as a parameter of the SIMILAR command term, and a column specified as a parameter of the SIMILAR command term;
Querying the database passing the specified row and the specified column using the SIMILAR command term to generate a predictive record set;
Returning the predictive record set in response to the query, the predictive record set having a plurality of elements therein, each of the returned elements of the predictive record set comprising: to the specified row passed by sIMILAR command terms, on the basis of the specified column, according to latent structure, the row identifier corresponding to rows of the data sets that are evaluated to be similar, (ii A confidence measure indicating the likelihood of a latent relationship between the specified row passed in the SIMILAR command and the row identifier returned for each of the elements;
Including methods. (I) the specified row passed in the SIMILAR command term in response to the query based on the prediction record set returned and a confidence index for each similar row returned in the prediction record set. And the most similar line compared to
(Ii) the specified row passed in the SIMILAR command term in response to the query based on the returned predicted record set and a confidence measure for each similar row returned in the predicted record set. The least similar line compared to
(Iii) a related product in the recommender system in response to a search by an Internet user, the related product corresponding to one of the similar rows returned in the predicted record set;
9. The method of claim 8, further comprising returning one of Publishing the database of the host organization includes exposing a Predictive Query Language Application Programming Interface (PreQL API) directly to the authenticated user, the PreQL API being public to the authenticated user. Accessible via the Internet,
Querying the database using the SIMILAR command term includes passing a PreQL query to the database, the PreQL query comprising:
The SIMILAR command term as a necessary term;
A ROW term as a required term, wherein the ROW term specifies a line to be passed in the SIMILAR command term; and
A COLUMN term as a required term, the COLUMN term specifying a column to be passed in the SIMILAR command term;
An optional FROM term that, when specified, specifies one or more tables, data sets, data sources, and / or indexes to be queried, wherein the optional FROM term An optional FROM term in which default values are used for the one or more tables, data sets, data sources and / or indexes to be queried when not specified;
An optional CONFIDENCE term that, when provided, specifies the minimum acceptable confidence measure to be returned in the predicted record set;
An optional COUNT term that, when provided, specifies the maximum quantity of elements to be returned in the forecast record set;
When provided, an optional ORDER BY that specifies whether the elements of the prediction record set should be returned in ascending or descending order according to a confidence measure for each element returned in the prediction record set Terms,
Has the query syntax of
The method of claim 8. A method in the host organization,
Generating an index from a data set of columns and rows, wherein the index represents a stochastic relationship between the rows and columns of the data set;
Storing the index in a database of the host organization;
Publishing the database of the host organization via a request interface;
Receiving at the request interface a query to the database specifying a GROUP command term and a column specified as a parameter of the GROUP command term;
Querying the database passing the specified column using the GROUP command term to generate a predicted record set;
Returning the predicted record set in response to the query, wherein the predicted record set has a plurality of groups designated therein, and each of the returned groups of the predicted record set includes the Including a group of one or more rows of a data set;
Including methods.   All of the rows in the dataset are in exactly one of the groups returned in the predicted record set without any overlap where any single row is assigned to two or more of the groups. The method of claim 11, delimited by assigning every row of the data set. The rows of the data set assign the rows of the data set to at most one of the plurality of groups without any overlap where any single row is assigned to two or more of the plurality of groups. Segmented by
The segmentation means that one or more rows of the data set remain unassigned to any of the plurality of groups, for the corresponding one or more rows left unassigned. Resulting from the confidence index of being below the minimum threshold,
The method of claim 11. Publishing the database of the host organization includes exposing a Predictive Query Language Application Programming Interface (PreQL API) directly to the authenticated user, the PreQL API being public to the authenticated user. Accessible via the Internet,
Querying the database using the GROUP command term includes passing a PreQL query to the database, the PreQL query comprising:
GROUP command terms as necessary terms;
A COLUMN term as a required term, the COLUMN term specifying a column to be passed in the GROUP command term;
An optional FROM term that, when specified, specifies one or more tables, data sets, data sources, and / or indexes to be queried, wherein the optional FROM term An optional FROM term in which default values are used for the one or more tables, data sets, data sources and / or indexes to be queried when not specified;
An optional CONFIDENCE term that, when provided, specifies a minimum acceptable confidence measure for rows to be returned in the group of the predicted record set;
Has the query syntax of
The method of claim 11. Receiving a tabular data set, the data set having a plurality of rows and a plurality of columns;
Generate an index representing the stochastic relationship between the rows and columns of the data set by learning a joint probability distribution across the data set, as identifying and explaining the stochastic relationship between elements of the data set Processing the data set as follows:
Determining a confidence quality measure for the generated index;
Storing the index in a database;
Exposing an application programming interface (API) for querying the index in the database;
Receiving a request for a predictive query or a latent structure query for the index in the database;
Querying the database for results based on the request via the API;
Returning the result in response to the request;
Including methods.   Learning the joint probability distribution is controlled by a specified configuration parameter, which includes a maximum period of time to process the data set, and a maximum number of iterations to process the data set. A minimum number of iterations to process the data set; a maximum amount of customer resources to be consumed by processing the data set; a maximum subscriber fee to be spent processing the data set; The minimum threshold predicted quality level to be achieved by processing the data set, the minimum improvement to the confidence quality measure necessary to continue the processing step, and the maximum or the index to be generated by the processing step, or The method of claim 15, comprising one or more of a minimum number. Processing the data set to generate an index includes iteratively learning a joint probability distribution across the data set to generate the index;
The method is
Periodically determining the reliability quality measure of the index generated by processing the data set;
Ending the processing of the data set when the reliability quality measure achieves a specified threshold;
16. The method of claim 15, further comprising: Receiving a predictive query or a latent structure query requesting results from the index generated by processing the data set;
Executing the query against the generated index before finishing the processing of the data set;
Returning a predicted record set in response to the prediction query or the latent structure query requesting the result;
Returning a notification with a result indicating that processing of the data set has not yet been completed, or a notification with a result indicating that the reliability quality measure is below the specified threshold, or both;
The method of claim 17, further comprising: Before Symbol reliability quality measure,
Comparing known results corresponding to values observed and present in the data set with predicted results obtained by querying the index generated by processing the data set, or ground from the data set Comparing truth data with one or more prediction results obtained by querying the index generated by processing the data set;
The method of claim 15, determined by one of the following: Receiving the data set includes receiving the data set at a host organization that provides an on-demand cloud-based service accessible to the remote computing device over the public internet;
The step of storing the index in a database includes operation logic stored in a memory of the prediction database system and executed via one or more processors of the prediction database system in a prediction database system operating in the host organization. Storing the index via
Publishing the API for querying the index includes publishing a Predictive Query Language (PreQL) API to the remote computing device.
The method of claim 15.

Images