Using Caché Objects - InterSystems Documentation

Relationships
Class MyApp.Company Extends %Persistent [ClassType = persistent]
{
Property Name As %String;
/// a Company has MANY Employees
Relationship Employees As Employee [Inverse = TheCompany, Cardinality = MANY];
}
and Employee:
class MyApp.Employee Extends %Persistent [ClassType = persistent]
{
Property Name As %String;
Property Title As %String;
/// an Employee has ONE Company
Relationship TheCompany As Company [inverse = Employees, cardinality = ONE];
}
14.2 Dependent Relationships
A dependent relationship, defined by having cardinality of PARENT on one side and CHIL-
DREN on the other, has the following additional characteristics:
• The existence of the child objects is dependent on the parent; if a parent object is deleted
then all of its children are automatically deleted.
• Once associated with a particular parent object, a child object can never be associated
with a different parent. This is because the persistent ID value of the child object is based
in part on the parent's persistent ID.
• As much as possible, instances of child objects are clustered with parent objects on disk
making disk access as optimal as possible (few page accesses are required to retrieve the
children for a parent).
• A dependent relationship is projected to SQL as a parent-child table.
• The two classes are linked at compile time, as opposed to a ONE-MANY relationship,
where the classes are compiled independently. Consequently, parent/child relationships
may only be defined between two different classes. The two sides of a dependent relationship
cannot be defined within a single class, or within a base class and its derived class.
For example, here are the definitions for two related dependent classes, Invoice and LineItem.
Invoice is:
128 Using Caché Objects