Questions about how the design patterns work within MM.Net and whether thinking about a particular situation should be looked at in terms of design patterns. There wasn't much discussion in the MM.Net documentation about this. I thought I'd send out a question before I started experimenting.

In building a new system, we have an "employee" table which becomes the primary business object for many of our forms. A subset of those forms also have the "employee history" table used as the child business object to the "employee" business object.

There are three questions:
1. Is it possible to have more than one business object identified as a child to a given business object?
2. Is it possible to have more than one level of business objects identified in parent/child relations? Specifically, the "employee history" business object contains a number of foreign keys to other business objects, e.g. "department" (the department in which the employee works). Can I specify "employee" as the primary business object, "employee history" as a child of "employee", and "department" (among others) as a child of "employee history"?
3. Assuming the situation in question 2 is reasonable, and I add a new "employee history" entry or make changes to an existing "employee history" entry for a particular employee, I will typically want to save only the changes to the particular employee history entry I have been working on. Based on what I know, it seems that the mmButtonSave button on the form should indicate that its BindingSource should be "EmployeeHistory" and it will save just the new or updated "employee history" data. Is this correct?

Explanations and examples (as opposed to simply "Yes, that works.") will be much appreciated.

Thanks for help / clarification.

Frank