Show TOC

Relationship PropertiesLocate this document in the navigation structure

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.

Keywords

Provide a way of loosely grouping objects through tagging. To enter multiple keywords, separate them with commas.

Cardinalities Tab

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:
  • One-to-one (<1..1>) - One instance of entity A can correspond to only one instance of entity B.

  • One-to-many (<1..n>) - One instance of entity A can correspond to more than one instance of entity B.

  • Many-to-one (<n..1>) - More than one instance of entity A can correspond to the same one instance of entity B.

  • Many-to-many (<n..n>) - More than one instance of entity A can correspond to more than one instance of entity B. To use n..n relationships in an LDM, see Enabling Many-to-many Relationships in an LDM.

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:

  • 0..1 – Zero to one instances

  • 0..n – Zero to many instances

  • 1..1 – Exactly one instance

  • 1..n – one to many instances

Joins Tab (LDM)

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.

On this tab, you can either:
  • Select an identifier from the parent entity in the Parent field on which to base the join to autopopulate the list with its associated parent and child attributes. If necessary, you can modify the specified child attributes.
  • Specify <None> in the Parent field and specify your own attribute pairs on which to base the join using the following tools:

    Tool

    Description



    Reuse Attributes - Create a join by matching parent and child attributes that share the same code.



    Migrate Attributes - First specify attributes in the Parent Attribute column and then click this tool to migrate them to foreign identifier attributes in the child table. If the attributes do not exist in the child table, they are created.



    Cancel Migration - Remove any attributes migrated to the child table.



    Insert a Row - Inserts a row before the selected row in the list to specify another attribute to join on.


    Add a Row - Adds a row at the end of the list to specify another attribute to join on.