Corticon provides the flexibility to either pass the data in on the call to the decision service or to have the decision service retrieve data, or a mix of both. What you choose depends on your needs.
In most Corticon deployments, the data is passed in. This simplifies the architecture because you don't need to account for Corticon connecting to external data sources. This is especially true when you have legacy systems which cannot be easily accessed. In some cases, the data passed in can be large. For example all the data needed to process a loan application for a single applicant.
In some deployments, Corticon needs to retrieve supporting data. This adds another connection to the architecture yet it can be a considerable savings to not have to pass in all the data in the request. This is especially true where the data is selective – when the rules are choosing some subset of data that is needed. This can also be useful with reference data that you want to cache.
In other deployments Corticon needs to retrieve the data for efficiency. An example would be a batch application where you need to process a billion records at the end of the month. In such cases, efficient moving of data is essential for performance.
How Corticon relates to a database
A Corticon Vocabulary is fundamentally relational in nature, and conceptually equivalent to the elements of a typical relational database:
Corticon Vocabulary
Relational Database
Vocabulary
Schema
Vocabulary: Entity
Table
Vocabulary: Attribute
Table Column or Field
Vocabulary: Association
Relationship between Tables
Ruletest Output
Table Row(s) or Record(s)
Your Corticon database integration design can be defined from two perspectives:
Start from the business perspective by converting a Vocabulary into a database. Because Studio is a powerful modeling environment, users often build Vocabularies "on-the-fly" in order to support their rule modeling. Assuming the Vocabulary design is acceptable to IT as the basis for a database, then Studio can be used to export schema information directly to a database engine and generate the necessary table structure within a defined tablespace.
Start from an IT perspective by abstracting a data model from an existing database and using its terms and structure to create a Vocabulary for rule modelers to use in their rule building and testing.
Start from the business perspective by converting a Vocabulary into a database. Because Studio is a powerful modeling environment, users often build Vocabularies "on-the-fly" in order to support their rule modeling. Assuming the Vocabulary design is acceptable to IT as the basis for a database, then Studio can be used to export schema information directly to a database engine and generate the necessary table structure within a defined tablespace.