In the initial PegaRULES database schema, these database tables contain rows corresponding to instances of concrete Data- classes:
pr_operators
— Operator IDspi_data_connect
— Listenerspr_data_admin
— Administrative data not stored elsewherepr_data_file
— Contains image content data instances (Data-Content-Image class) pr_data_tag
— Contains all of the unique tags defined in the system pr_data_products
— Supports display of installed hotfixes pr_data_restore
— Stores metadata required to rollback hotfixes pr_data_sample_uidetails
— Supports data for the UI Gallerypc_data_uniqueid
— Work item ID trackingpc_data_workattach
— Work item attachmentspr4_base
— Foundation objectspr_data_autotest
— Test results from use of the Automated Testing featurepr_data
— Sent correspondence and data objects not stored elsewherepr_class_ancestors
— Supports high-performance rule resolutionThe pr_operators
table contains rows that correspond to instances of the Data-Admin-Operator-ID class. The key to this table consists of the class name and Operator ID, for example:
DATA-ADMIN-OPERATOR-ID [email protected].
As a best practice, retain Operator ID records permanently; do not delete rows that correspond to departed operators. You can change the operator password to prevent anyone from logging on, and can mark the operator as unavailable for work.
The Storage Stream column (pzPVStream) of this table contains user passwords in hashed form. For maximum security of your system, do not alter the schema for this table to expose this property as a column.
The pi_data_connect
table is associated with the Data-Admin-Connect- class. Instances of the classes derived from this class support service listeners and related interface data.
For example, JMS listeners are instances of the Data-Admin-Connect-JMSListener class.
The pr_data_admin
table holds instances of classes derived from the Data-Admin- class, excluding those explicitly mapped to other tables:
For example instances of the Data-Admin-System-Settings class are mapped to the pr_data_admin
table.
The pc_data_uniqueid
table corresponds to the Data-UniqueID class, and contains a single row for each work item ID format in use. This row records the most recently assigned work item ID of that format, usually computed by a stored procedure.
For example, if most recent purchase order is PO-4253, then when the next purchase order is entered, the value of property pyLastReservedID increments to 4254.
Attachments to work items are instances of concrete classes derived from the Data-WorkAttach- class. In the initial PegaRULES database schema, this class is linked to the pc_data_workattach
table. (However, the attachment itself is included for content or "ECM" attachments, which are saved in an external document repository and are accessed through Connect CMIS rules.)
The pzInsKey value for a work item attachment consists of values of these properties, concatenated into a single string:
DATA-ADMIN-WORKATTACH-FILE
For example, a note attached to work item W-15 on November 10, 2009 may have the following pzInsKey value:
DATA-WORKATTACH-NOTE PEGASAMPLE W-15!20091110T195841.692 GMT
Some applications in production may create and retain millions of work item attachments; other applications may not to use attachments at all.
Instances of the Data-WorkAttach-File class may contain an uploaded file of any type, up to 1 Gigabyte in initial size, which is converted to text if necessary using Base64 encoding. Instances of the Data-WorkAttach-ScanDocument and Data-WorkAttach-ScreenShot classes both contain images, also converted using Base64 encoding.
Instances of these three Data- classes are associated with the pr4_base
table:
These are known as foundation classes.
Instances of two Data- classes that support use of the features of Automated Unit Testing are associated with the pr_data_autotest
table:
See About Automated Unit Testing.
Instances of the Data-Content-Image class are associated with the pr_data_file
table. See About Image Content data instances.
These tables are not used:
When you create a data table using the Data Table wizard, you can optionally cause instances of the data table class be stored in a new database table. This choice simplifies future migration of the contents of the database table if necessary, and can improve performance and facilitate reporting on data table contents. Typically, the data table class is derived from the Data- base class and the new table is named pr_zzzzz, where zzzzz is the class name.
Note: With Pega 7.1.7 local data storage replaces data tables.
The pr_data
table holds instances of any concrete class derived from the Data- base class not covered by the tables listed above. For example, (as initially configured during installation) the Data-Party-Com, Data-Party-Person and Data-Corr-Email classes map to this table.
The pr_data
table has only few exposed columns. As a best practice for good performance, evolve your PegaRULES database so that any classes with many saved instances or high activity are not mapped to this table.
For example, some applications in production may have thousands or millions of people identified through Data-Party-Person instances, or create millions of outgoing email messages saved in the Data-Corr-Email instances. As a best practice, create new dedicated tables with exposed columns for such classes, or add indexes to eliminate table scans and add exposed columns to avoid retrieving the Storage Stream.
A few Data- classes (for example Data-RuleSearch and Data-Work-Summary) are mapped to the pr_data
table but do not in fact correspond to any rows of that table. These classes are the Applies To class of specialized reports that access various database tables through custom getContent activities; running the reports does not access the pr_data
table.
attachment, available user, Data- base class, listener, Operator ID, tag, work item ID | |
Atlas — Initial Database Table data instances Atlas — Standard classes derived from the Data- base class |