Browse Prior Art Database

A Method for Using Only Business Keys when Processing Events to Update Profiles for Business Intelligence and Predictive Scoring. Disclosure Number: IPCOM000237613D
Publication Date: 2014-Jun-27
Document File: 6 page(s) / 131K

Publishing Venue

The Prior Art Database


Disclosed is an Application Programming Interface (API) implementation that uses only business keys, but easily supports references, during event processing.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 01 of 6

A Method for Using Only Business Keys when Processing Events to Update Profiles for Business Intelligence and Predictive Scoring.

Electronic messages representing events can be processed to support Business Intelligence and Predictive Analysis solutions. The goal of these solutions is often to provide insight into why certain events occur (such as device failure) and why the events contain specific values (such as quantity produced). Advanced solutions of this type can also provide specific recommendations for actions that can (based on predictive models and rules) produce certain desired outcomes or avoid undesired outcomes.

Event processing may involve storing the event, aggregating values such as counts and averages to profile tables, calling predictive scoring and decision management, and issuing a recommendation. These steps often involve database operations to insert, update, and retrieve values. It is common for events and profiles to contain references to data in other tables (master data). These references use the concept of a key to identify a specific row in the database . A key is a set of one or more values that form a unique combination. These values (i.e. Business Keys) typically have meaning to a user such as a device serial number or a location code.

When one database row references another, it must contain the business keys that identify the referenced row. For performance reasons, the database implementation may use a single Surrogate Key to actually implement the reference . This surrogate key value has no meaning to the user and introduces an additional level of complexity. Ideally, the use of this key would be an implementation detail and users would only be aware of the business keys. In addition to the user complexity, exposing the surrogate keys can introduce unwanted dependencies.

An application programming interface (API) for rows with references typically requires the user to first use a set of key values to obtain the referenced row and then use either the reference the row (Figure 1) or the associated surrogate key (Figure 2) to populate the reference.

Figure 1: A device row object referencing a location row object directly


Page 02 of 6

Figure 2: A device row object referencing a location using a surrogate key

Therefore, it is desirable to have an API implementation that uses only business keys but easily supports references .

The proposed solution is an API implementation that removes both the need for the user to be aware of surrogate keys , and the need to resolve references. This is achieved by "in-lining" the business keys for all references into fields in a Row object. Thus, rather than having a field that directly references the Row or requires an associated surrogate key, the API supports having a field for each business key. (Figure 3) This includes the case of having a reference as part of the key of the referenced table , in a chain of references (e.g., row a references row b, which refe...