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_TAX_ROLE 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.
Note:
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).
Note:
Iterative conversions. Rather than perform
a "big bang" conversion (one where all taxpayers are populated at
once), some implementations have the opportunity to go live on subsets
of their taxpayer 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 taxpayers, you can be assured
of getting clean keys. Note that iterative conversions of tax types
for existing taxpayers is not currently supported.
Note:
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. Conversion for classic billing
is no longer supported. However, 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.
Note:
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 © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]