|
The PegaRULES database as initially installed consists of about XXXXX 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 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. CLINB clinic and SharePoint
1/6/09
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.
See the Pega Developer Network article 
PRKB-26007 About PegaRULES table partitioning.
Working with the PegaRULES database
Help Home