As said, you probably need to think about the behaviour of your objects and not your database schema. Would you class Award and AwardVestingSettings as different objects, or one object that just happens to reside in more than one database table?
If they're two seperate objects then it could be worth using two datasources instead of one, with the second datasource calling AwardVestingSettings.GetAwardVestingSettings(award.VestingSettingsId);
If they do need to be a single object then it could be worth storing the AwardVestingSettings object internally to the Award class. You can then expose the AwardVestingSettings properties on the Award class.
Here's another example that may help:
A Customer may have a primary Address (mandatory) as well as a collection of other addresses (shipping, billing, alternate addresses etc). The primary address will be a 1-1 to the customer, and an application may treat the primary address as such. This will allow you to do the following:
Customer newCustomer = Customer.NewCustomer();
newCustomer.Name = "Bob Monkhouse";
newCustomer.StreetAddress = "41 Country Lane";
Internally the street address is being stored in an Address object, but the user of the object does not need to see that. It also makes databinding clearer.
The Customer class would contain the following:
public string StreetAddress
{
get
{
return this.primaryAddress.StreetAddress
}
}
I hope this helps.
UK Daaarn Saaarf