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 key is allocated, the key assignment program checks the corresponding 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 a table whose prime key is a system-assigned is defined on its table definition record.
• 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.