To view or edit a relationship's properties, double-click its diagram symbol or Browser or list entry. The property sheet tabs and fields listed here are those available by default, before any customization of the interface by you or an administrator.
The General tab contains the following properties:
Property |
Description |
---|---|
Name/Code/Comment |
Identify the object. The name should clearly convey the object's purpose to non-technical users, while the code, which is used for generating code or scripts, may be abbreviated, and should not normally include spaces. You can optionally add a comment to provide more detailed information about the object. By default the code is generated from the name by applying the naming conventions specified in the model options. To decouple name-code synchronization, click to release the = button to the right of the Code field. |
Stereotype |
Extends the semantics of the object. You can enter a stereotype directly in this field, or add stereotypes to the list by specifying them in an extension file. |
Entity1 Entity2 |
Specifies the two entities linked by the relationship. Use the tools to the right of the list to create, browse for, or view the properties of the currently selected object. |
Generate |
Specifies that the relationship should be generated as a reference when you generate a PDM. |
Cardinalities |
Contains data about cardinality as the number of instances of one entity in relation to another entity. |
Keywords |
Provide a way of loosely grouping objects through tagging. To enter multiple keywords, separate them with commas. |
The Cardinalities tab allows you to specify the nature of the relationship between the two entities. The following properties are available:
Property |
Description |
---|---|
Cardinality |
Specifies the number of instances (none, one, or many) of an entity in relation to another entity. You can choose from the following values:
For information about the termination points of the relationships in each of the supported notations, see Supported CDM/LDM Notations. |
Dominant role |
[one-to-one relationships only] Specifies one direction of the relationship as dominant. If you define a dominant direction, the one-to-one relationship generates one reference in a PDM, with the dominant entity as the parent table. If you do not define a dominant direction, the one-to-one relationship generates two references. In the following example, the author is the dominant entity: In a PDM, this relationship generates a reference with Author as the parent table, and its primary key migrated to the Picture table as a foreign key: |
In addition, this tab contains a groupbox for each direction of the relationship, containing the following properties:
Property |
Description |
---|---|
Role name |
Text that describes the relationship of EntityA to EntityB, and which is used to generate the assertion statements displayed at the top of this tab. You should use the infinitive phrase that describes the relationship of one entity to the other. For example, Each Order may contain one or more line., and Each line must belong to one and only one Order. To modify the sentences generated from your role names, edit your model's assertion template (see Assertion Template). |
Dependent |
Specifies that the entity is dependent on and partially identified by the other entity. In the following example, the task entity is dependent on the project entity. Each task is a part of a project and each project can contain zero or more tasks: |
Mandatory |
Specifies that each instance of the entity requires at least one instance of the other entity. For example, the subcontract relationship is optional from customer to project, but mandatory from project to customer. Each project must have a customer, but each customer does not have to have a project. Implied by dependent |
Cardinality |
Specifies the maximum and minimum number of instances of EntityA in relation to EntityB (if mandatory, at least 1). You can choose from the following values: |
The Joins tab lists the joins defined between parent and child entity attributes. Joins can link primary, alternate, or foreign identifiers, or any user-specified attributes.