A Note About Keys
The prime keys of the tables in the staging database are either system-assigned random numbers or they aren't. Those tables that don't have system-assigned random numbers have keys that are a concatenation of the parent's prime-key plus one or more additional fields.
Every table whose prime key is a system-assigned random number has a related table that manages its keys; we refer to these secondary tables as "key tables". The following points provide more information about the key tables:
• Key tables are used by programs that allocate new keys. For example, before a new account ID is allocated, the key assignment program checks the account key table to see if it exists.
• Key tables only have two columns:
◦ The key of the object.
◦ An environment ID. The environment ID identifies the database in which the object resides.
• Key tables are named the same as their primary table with a suffix of "_​K". For example:
◦ The key table for CI_​ACCT is CI_​ACCT_​K
◦ The key table for CI_​PREM is CI_​PREM_​K
• The name of every table's key table is defined under the Generated Keys column in the Table Names sections in The Staging Tables.
• When you populate rows in tables with system-assigned keys, you must also populate a row in the related key table. For example, if you insert a row into CI_​ACCT, you must also insert a row into CI_​ACCT_​K. The environment ID of these rows must be the same as the environment ID on this database's installation record.
◦ When you populate rows in tables that reference this record as a foreign key, you must use the appropriate key to ensure the proper data relationships. For example, if you insert a row in CI_​SA for the above account, the ACCT_​ID column must contain the temporary account key.
• When you insert rows into your staging database, the keys do not have to be random, system-assigned numbers. They just have to be unique. A later process, Allocate Production Keys, will allocate random, system-assigned keys prior to production being populated.