A shadow table is created for the primary entity represented by the MAPPER report to hold MAPPER "metadata". More specifically, each shadow table row contains the cabinet, drawer, report and line of the MAPPER report from which the entity data tuple was extracted and loaded into the corresponding, entity database table. This metadata is presumably useful to the migrated application.
Note that a shadow table is not created for an entity extracted from inline data in trailer lines. Such a "secondary" entity generally has a relationship with the primary entity. Therefore, by association, the shadow table for the primary entity provides MAPPER metadata for the secondary entity as well.
The shadow table exists primarily for backward compatibility with MAPPER artifacts that cannot be removed in the initial version of a migrated application. For example, if multiple MAPPER reports containing partitions of data for the same entity are loaded into a single database table, retaining the origin of the data (such as legacy drawer or report number) may be useful to the first iteration of an MJ application. When dependencies on data origin and ordinal position (represented by line numbers) are eliminated from the migrated application, the shadow table may simply be dropped.
MJ creates a Hibernate-based, persistence class with prefix "MJ" for the shadow
table as a useful artifact to the migrated application. For example, a diagram of the relationship between
FootwearOrderLineitem entity class and
class from the Footwear Orders report is shown below:
The Oracle DDL to create the
shadow table is shown below:
create table MJ_FOOTWEAR_ORDER_LINEITEM ( FW_ORDER_LI_ID number(19,0) not null, MJ_CABINET number(5,0), MJ_DRAWER char(1), MJ_REPORT number(5,0), MJ_LINENUM number(10,0), MJ_LINETYPE char(1), PRIMARY KEY (FW_ORDER_LI_ID) );