|
The PegaRULES database as initially installed consists of about 60 tables that hold all the rules, data instances, work objects, history, and other concrete objects from internal classes of your Process Commander system. Views, indexes and stored procedures support performance and other processing requirements.
By definition, external classes correspond to tables in other databases. These tables are not part of the PegaRULES database.
A database administrator can modify and evolve the PegaRULES database to meet policy, security, performance, and reporting requirements.
Tables and views in the PegaRULES relational database become visible through Database Table instances (Data-Admin-DB-Table).
For example, the Data-Admin-Operator-ID class
defines users and their organization. The property
pyUserName in that class can contain as its
value a text string for a user name. When your system is
first installed, instances of the
Data-Admin-Operator-ID class are saved as rows
in the pr_operators database table, identified
in the database table instance named
Data-Admin-Operator-ID. The column named
pyUserName contains the text string for the
name.
Your applications can use list view rules, summary view rules, or the Obj-Browse method to generate SQL statements that search the database and generate reports for managers or developers. (You can also use Connect SQL rules to search the database, but this is not recommended except in unusual situations.)
In a production system, you can reduce the performance impact of report queries on the PegaRULES database by mirroring all or part of the database (through normal database software capabilities) and identifying the mirror as a reports database in the Database table instances.
For security and performance reasons, Process Commander uses prepared statements when accessing the PegaRULES database. The SELECT, WHEN, and other parts of the SQL statements are parameters to the prepared statements.
You can host the PegaRULES database on a separate server from the server (or servers) that execute Process Commander rules. In such configurations, ensure that, communications between the Process Commander servers and the database server have high bandwidth and very low latency. In a wide area network where the database server is remote from one or more Process Commander servers, local database replication may be necessary to achieve good performance.
A snapshot of the schema as installed is available in HTML
format on the installation media. Open the
/schema/docs/ subdirectory and display the
index.html topic. This shows the mapping of
classes to tables:
Click a link in the Table column to see the exposed
properties in one table, such as pc_work:
This information does not reflect any changes made to your PegaRULES database schema since the system was installed.
Viewing
and modifying the current database schema
Use the Modify Database Schema wizard to see the current schema of any table in any database that your system accesses.
If the Database data instance (Data-Admin-DB-Name
class) for the PegaRULES database contains appropriate
User ID and password for the database, you can select a
Single Value mode property from the
pzPVStream column and make it an exposed column.
See How to
expose a property as a database table column.
When an existing Process
Commander system is upgraded to a new version, SQL scripts
may update the standard tables. To avoid possible collisions
or other issues with future upgrades, make schema changes
(other than simple new columns) only to copies of the
standard tables and views. Adjust table rows and
Data-Admin-DB-Table mappings to reference your
copies. This is especially important for database views, as
upgrade processing may drop view definitions and add revised
view definitions.
Working with the
PegaRULES database
Home