To achieve the merger of the two data sets, we create proxy transformations that map the Sample source attributes to target attributes as described in Table 9-1, “Attribute Mapping”. The schema already defines an attribute to contain the RDN of user entries, called uid. However, chooses to create two new attributes within its exampleAccount object class to accommodate two attributes in the Sample schema for representing the region and the DN of linked accounts.

During the merger, decides to re-parent Sample’s customer entries, which are defined under two different subtrees, ou=east,o=sample and ou=west,o=sample, placing them under’s ou=people,dc=example,dc=com subtree. Associated proxy transformations are described in Table 9-2, "DN Mappings". In this process, collapses the Sample tree, moving entries from the east and west region under a single DN, dc=example,dc=com. The DN proxy transformations assume that all Sample users have been co-located under this single subtree.

Sample Attribute Attribute Description
sampleID uid RDN of user entries
sampleRegion exSampleRegion String value representing the region
sampleLinkedAccounts exSampleLinkedAccounts DN value

Legacy Sample LDAP applications searching for entries in either the Sample base DN ou=east,o=sample or ou=west,o=sample will be successfully serviced, though there will be one or more differences in the user entries seen by the Sample legacy applications. Since the Directory Server has no knowledge of the Sample user’s former ou=east or ou=west association, search results for client searching under o=sample will return a DN that may differ from the original search base. For instance, a search for sampleID=abc123 under ou=west,o=sample may return the user entry for abc123 with the DN of sampleID=abc123,ou=east,o=sample. The following table illustrates the mapping DNs.

Sample DN DN
ou=east,o=sample dc=example,dc=com
ou=west,o=sample dc=example,dc=com
o=sample dc=example,dc=com