Data Modeling Tips & Tricks: Relationships

Creating a refined data model can be tricky especially when many relationships are involved. Use these tips and tricks to create quick and easy simple relationships within your data model. This post will cover a few common user sticking points Telvent has seen, Telvent conventions, and recommendations, as well as examples of each.

Conventions increase not only the ease of developing the data model but also the ease of reading for the end user. There are a number of conventions for Telvent data models overall, and some specifically for relationships. The following information references simple binary and composite relationships.

Naming:
When naming a relationship, the name is the Parent class followed by an underscore then Child class.  
 

• First End Name listed is the parent
  •  DevicePoint  
• Second End Name listed is the child
  •  Device

  For example, if there is a 1:* relationship between DevicePoint and Device, the relationship name would be DevicePoint_Device (see image below). 

  WHY the naming convention?

  First, it’s easier to quickly view any mistakes in parent/child direction.  
  Second, if you run into errors, the error will list the relationship name. It is much easier to locate the DevicePoint_Device relationship name then it is to locate, for example, Association27_Association28 relationship name (the default name).

Ensure association ends match association points and cardinality: 
The snap point from the relationship to the class needs to correspond to the Parent/Child end.

The image below shows both the standard relationship name, DevicePoint_Device, as well as the location of the cardinality 1:*. As shown, the DevicePoint is the Parent class (listed first and with the 1 cardinality) and Device is the Child class (follows the underscore with the * cardinality). A reader can easily see that the Parent is the class listed first in the relationship name, and that has the cardinality of 1. 
 

When assigning the relationship there are a few things that you need to remember:

• In the Association Ends section, the first End Name is the Parent and the second is the Child.

For example, the first name listed is Support Structure and is therefore the Parent (see image below).

• The Aggregation column is only used in a composite relationship. Binary relationships use the default of none.

• The Visibility column has no bearing on the visibility of the relationship or anything else needed for data modeling. Default is private.

• The Multiplicity column shows the cardinality of the relationship. The first name entry is for the Parent so its cardinality is 1 or *. The second entry is for the Child cardinality.

Check back for future posts on additional data modeling tips & tricks!