The next process is to consider which columns/fields in the original data belong to which data objects. In OOP, each individual data column or field is described as a property of the host data object. So this process is actually mapping the original data fields to object properties.

The data will already be separated in the process of defining the data objects, but it is a good idea, at this stage, to work through each property and check that the best fit is used to associate it with its data object. As with choosing which objects to use, there can be some ambiguity in choosing which object a property is best associated with, and again it is a designer's task to choose the best association to suit the case at hand.

Rory's rules 2 and 3 help here again. For example, the city that has a company belonging to it may be useful when trying to group companies together. So it could be held within the company data. However, the city is more closely related to addresses (rule 2). Rory thinks the benefits of having the city property in the company area is far outweighed by the significant benefits in associating city with the rest of the components that go together to make an address (rule 3). Therefore, the city property is put with the address object.

Considering the data objects in relation to the real objects that they represent, also helps to choose where to hold telephone data. For example, mobile telephones belong to individual people, and therefore the mobile telephone numbers should be stored within the people object. On the other hand, switchboard telephone numbers relate to a company and therefore need to be within the company object.