It's important to understand that the system does not overwrite the prime-keys or foreign keys on the rows in the staging database, as this is a very expensive IO transaction. Rather, a series of tables exist that hold each row's old key and the new key that will be assigned to it when the row is transferred into the production database. We refer to these tables as the "old key / new key" tables. The old key / new key tables are named the same as their primary table, but rather than being prefixed by "CI", they are prefixed by "CK". For example, the old key / new key table for CI_ACCT is called CK_ACCT.
The insertion programs that transfer the rows into the production database use the new key for the main record of the key along with any other record where this key is a foreign key. Note that the capability of assigning the new key to a foreign key applies to
"True" foreign keys, i.e. where the key is a column in another table. For example, CI_SA has a column for ACCT_ID.
FK reference characteristics. These are characteristics that define, through an FK reference, the table and the key that this characteristic represents.
The insertion programs are not able to assign "new keys" to foreign keys defined in an XML structure field (CLOB).
The key assignment programs listed under Master Data and Transaction Data (in the table names sections) are responsible for populating the old key / new key tables (i.e., you don't have to populate these tables). Because the population of the rows in these tables is IO intensive, we have supplied detailed instructions that will accelerate the execution time of these programs.
Why are keys reassigned? The conversion process allocates new prime keys to take advantage of the system's parallel processing and data-clustering techniques in the production system (these techniques are dependent on randomly assigned, clustered keys).
Iterative conversions. Rather than perform a "big bang" conversion (one where all customers are populated at once), some implementations have the opportunity to go live on subsets of their customer base. If this describes your implementation, please be aware that the system takes into account the existing prime keys in the production database before it allocates a new key value. This means when you convert the next subset of customers, you can be assured of getting clean keys.
Optional Foreign Keys. One responsibility of the key allocation programs is to generate a single "zero" entry in its key table to represent a blank foreign key. This step is required by the subsequent Insert programs so that they may correctly insert new rows where optional foreign keys are blank. For example, the CI_FT table has a foreign key to BILL_ID. If your implementation does not plan to convert bills but does plan to convert FTs, the key generation program for Bills must still be run in order to generate the entry in the CK_BILL table for the "zero" row. This is needed by the FT Insertion program. The details of which Key Generation programs are required for successful run of a given insert program are detailed in each staging table section.
Program Dependencies. The programs used to assign production keys are listed in the Table Names matrices. Most of these programs have no dependencies (i.e., they can be executed in any order you please). The exceptions to this statement are noted in Program Dependencies.
Copyright © 2011, Oracle and/or its affiliates. All rights reserved.