In either case separate rules should be used to define the creation of the separate/alternative target instances.
If the instances created actually form closely bound parts of a single concept (e.g., if classes are mapped to both a table and its primary key, in a UML to relational database mapping), then the rule should not be split. This variation of the pattern could be termed Structure Elaboration. One way of identifying this case is that the rule establishes links of an aggregation association or other mutually mandatory relationship between the respective target elements, such as T1 1..*---1 T2 or T1 1---1 T2 associations.
An example is given in (Kurtov et al, 2006) of the application of this pattern to the creation of MVC components from source data: source model objects of types such as OpenElement are transformed in a single rule into interconnected model, view and controller objects Open, OpenView, OpenController.
The single rule for OpenElement could be written as:
for e : OpenElement
create t : OpenView; op : Open; oc : OpenController
satisfying t.obsId = e.id and
op.modId = e.id and op.observer = t and oc.view = t
Since the entities Open and OpenController depend on (refer to) OpenView, we can split the rule into three separate rules using the pattern: the first creates OpenView objects, the second creates Open objects and links each of these to the OpenView objects with the same id value, and the third does the same for OpenController.
The motivation for applying the Entity Splitting pattern in this case is to avoid the tangling of several different source-target relationships in a single rule, and instead to separate out these relationships into different rules. It may be necessary to define in the separate target entities some key attribute or stereotype which records the fact of the semantic link between them (i.e., that they represent separate parts of the same source entity). This allows the definition of a reverse relation.
Other examples are refinement or code-generation transformations such as the generation of multiple Java Enterprise Edition elements (database tables, value objects, EJBs) from single UML classes.
The Target Model Splitting architectural pattern can be used to store in separate models the instances of separate target entity types T1 and T2 derived from a source entity S1, if there are only implicit links between the two target types, and not explicit object references.
(Iacob et al, 2008) M. E. Iacob, M. W. A. Steen, L. Heerink, Reusable model transformation patterns, Enterprise Distributed Object Computing Conference Workshops, 2008, pp. 1--10, doi:10.1109/EDOCW.2008.51.