Merging Mappings for Weaving

A function takes one or more input values and produces an output value. For example, the square root function takes a set of real numbers or integers say, {25, 16, 9} and generates a different set of real numbers or integers in this case, {5, 4, 3}. Such a mapping can be stated as a rule (in other words, what we normally think of as a function), or as an enumeration {25:5, 16:4, 9:3}.

This abstruse factoid applies equally to mapping functions. Specification of mapping functions tends to focus on defining rules, but enumerations, while less sexy, are important when a rule can't easily be specified. It may even be the case that it's impossible to specify a rule. Both rules and correlations (enumerations of pairs of elements, one each from the source model and the target model) are both kinds of mapping functions.

For example, assume that a source model for a typical business is to be transformed into a database schema.

• A Customer business entity would correspond with a Customer table that has columns for the Customer's SSN, Name, and Date Of Birth.

• An Address object would correspond with an Address table that has columns for the City, its Postal Code, and the Street.

• An Account business entity would correspond with an Account table that has columns for Account Number and Balance.

To represent the relation between Customers and their Accounts, there would be an additional Account Ownership table, with columns for the SSN of the Customers owning given Accounts and the Account Number of the Accounts owned by some Customers.

The problem is to produce names for the tables and columns in the database. In general, there's no straightforward way of knowing that the Balance column of the Account table corresponds with the Balance attribute of the Account business entity. It might be possible to apply naming heuristics in this example, but that notion will certainly be shredded by real-world database administrators insisting on proven corporate database table-naming schemes. So, we need to correlate the elements in the source model with elements in the target model.

If the database naming convention is to name tables based on the class name and the type of entity (class or relation), then the correlations might look like this:

Source Model Class	Target Model Table
Customer	CustomerTable
Account	AccountTable
AccountOwnership	AccountOwnershipRelation

Similarly, if the convention is to name columns based on a four-character-maximum abbreviation based on the class name, and to limit column names to ten characters in total, then there will be another table that correlates source model attributes to target model columns:

Source Model Attribute	Target Model Column
Customer.Name	Cust_Name
Account.Balance	Acct_Bal
AccountOwnership.SSN	AccOw_SSN

In each table, the left-hand column identifies elements from the source model and the right-hand column captures the corresponding element in the target model.

As usual, the mapping function relies on elements of the metamodel. In the example, then, the mapping function declares a correlation between Attribute on the one hand and Column on the other. The mapping populates this correlation definition with values (Customer.Name, Cust_Name), (Account.Balance, Acct_Bal), and so forth. These correlations define join points; see (Mellor and Balcer) for more on this topic. We also provide a more detailed example in Chapter 9.