Table of Contents

Search

  1. Preface
  2. Backing Up and Restoring the Data Vault
  3. Configuring Centera as a Remote Data Vault Store
  4. Configuring Data Archive for a Legacy Source Using Legacy Adapters
  5. Data Archive Seamless Access for PeopleSoft
  6. Data Archive Transaction Restore API
  7. Dropping and Truncating Partitions in Data Archive
  8. How to Create Business Rules to Archive and Purge Transactional Data
  9. How to Uninstall Data Archive 5.1
  10. How to Uninstall Data Archive 5.3
  11. How to Use Scripts to Change Database User Passwords in the ILM Repository
  12. IBM DB2 Database Connectivity and Setup for Data Archive
  13. Installing Data Visualization
  14. Integrating Third-Party Schedulers in ILM Engine
  15. Parallel Processing in Data Archive
  16. Seamless Access Configuration for Siebel Applications
  17. Seamless Access Setup for Oracle E-Business Suite
  18. Using the Data Vault Service JDBC Driver to Connect to the Data Vault
  19. Using Multiple Engines in an ILM Environment
  20. Using PowerExchange ODBC Connections in a Data Archive Retirement Project
  21. Discovering Foreign Key Relationships in Enterprise Data Manager

Data Archive How-To Guide

Data Archive How-To Guide

Candidate Generation Process

Candidate Generation Process

The previous section stated that the end result of Candidate Generation is a "list of transactions that can be archived and purged". First, what is a transaction? A transaction is a functional business object like an Invoice or a Payment or a Sales Order. In a relational database, the transaction is represented as a series of tables. If we think of a database entity relationship diagram, there is a table at the "top" of the model. This is the driving table. In a relational database, "children" tables are related to the driving table through "foreign key" relationships.
The diagram below illustrates how a transaction may be represented in a relational database:
Second, the list of candidate transactions is actually a table in the database. This table is called an "interim table". The table contains the primary key (PK) of the driving table. Using the PK, Data Archive can identify the related pieces of the transaction (e.g., the Lines, Notes and Attachments in the diagram above). Data Archive uses the interim table to perform the archive and purge of all the transaction tables.
Finally, candidate generation also tells why transactions cannot be archived and purged. This information is also stored in the interim table. For each transaction the interim table tracks what business rules a transaction has passed or failed. The results of the business enforcement are tracked as columns in the interim table.
An interim table may be constructed as follows:
HEADER_ID
PURGEABLE_FLAGHAS_INVALID_PAY_STATUS
HAS_NEGOTIABLE_CHECKS