Peer relationships

[joselv]

Hello,

I am still having some trouble identifying when exactly I should use a peer relationship vs a parent/child one.

I have looked at some of the sample applications and a lot of them seem to use the peer relationship, but it seems to me that they could also use the parent/child.

Can someone point me in the right direction or resource to gain a better understanding of this? I've watch the relationships video several times and have read the guide but it is just not sinking in. The fact that I may be stuck in the traditional relational DB paradigm could be confusing me as well.

Thanks!

Jose

[customaware]

There are 3 different types of Reference (Relationship)
Peer
Owns
Owned By
Scenario 1:
Business Object (BO) called Parent (note… get in the habit of naming Business Objects in the singular rather than plural. Ie. Parent, not Parents)
Business Object (BO) called Child
Logically…
A Parent OWNS many Child.
A Child is OWNED BY a Parent
If a Parent is deleted then the Children should be deleted (Aware automatically enforces cascading deletes for OWNED children)
I can create a Reference Attribute in Parent of data type Child and if I wanted the above logic to hold then the type of Reference needs to be Owns
If my parent can have many Children then it also needs to be checked as Multiple.
So that creates what I refer to as a ‘Hard’ link between parent and Child.
Additionally, If I think I might need to know at some time in the future… “As a Child, Who Owns me?” Then I can create the Matching reference in the Child BO.
You can do that at the bottom of the same dialog screen where you create the Owns reference.
Obviously, is A Owns B, then B is Owned By A.
So in our example above…. In the Parent BO, create a Reference Attribute an name it om_Children (Owns Many Children) and check it Multiple. Immediately below
Create the matching attribute (this will be created in the Child BO) can call it ob_Parent (Owned By Parent)
Now you automatically have the reference Attribute placed on the Parent Form (default is a table of items but you can change it on the form) AND you will automatically
have the Opposite Parent attribute added to the Child Form (which you would usually go and delete)
Scenario 2:
Peer References….. In contrast to the style of relationship above, think about this.
I have a BO called Employee and another called Department.
An employee needs to be assigned to zero or 1 only Department
A Department can have many Employees assigned to it.
The reason we want a Peer Reference here is because, if I delete an Employee then I DO NOT want the Department list to be touched.
There is no cascading delete required here. Hence, I refer to this as a ‘Soft’ link between Employee and Department.
So, In the Employee BO, create an Attribute called ps_Department (Peer Single Department). As you can imagine, this would most likely be a drop down combo box
on the Employee Form.
At the same time, create the matching Attribute and call it pm_Employee (Peer Many Employee). This will create a multiple peer reference in the Department BO.
The Reference in the Employee BO is checked as Not Multiple. But the reference in the Department BO is checked as multiple.
So, as we assign a Department to each employee….. we can very easily see (will be a default table on the Department Form) all the Employees that have been assigned to the Department.
Scenario 3:
Aware IM is an extraordinary tool and allows things that a normally taboo in most all other Database design tools.
Usually a Many to Many relationship is forbidden. In every other environment I have ever seen, you need to break a M:M relationship down by incorporating
an intermediate Table so that you end up with two 1:M relationships to that table.
However, amazingly, Aware allows M:M for Peer References (but not for Owned)
Consider the following scenario….
I have a BO called Student and another called Class.
A Student can take zero, one or many classes.
A class can be attended by zero, one or many students.
Again, if I delete a Student, I do not want a Class deleted and visa versa. Hence Peer.
So in the Student BO create a reference attribute of the Class data type and call it pm_Classes (Peer Many Classes) and create the matching reverse attribute
called pm_Students (Peer Many Students) which will be added to the Classes automatically.
A default table of Classes for a Student will be added to the Student Form and a default table of Students will be added to the Class Form.

[joselv]

Thank you for detailed explanation! I am going to play around with these scenarios.

Jose