Where should relationships and determinants be created?

Should relationships be created between data source query subjects, between model query subjects, or between both? The answer depends on the complexity of the data source that you are modeling.

When working with data source query subjects, relationships and determinants belong together.

When working with model query subjects, there are side effects to using relationships and determinants that you should consider:

  • The model query subject starts to function as a view, which overrides the As View or Minimized setting in the SQL Generation type for a query subject.

    This means that the SQL stays the same no matter which items in the query subject are referenced. For more information, see What is minimized SQL?.

  • The model query subject becomes a stand-alone object.

    This means underlying relationships are no longer applied, except those between the objects that are referenced. It may be necessary to create additional relationships that were previously inferred from the metadata of the underlying query subjects.

  • When a determinant is created on a model query subject, the determinant is ignored unless a relationship is also created.

Here is an example of a relationship on a model query subject that purposely overrides the Minimized SQL setting and simplifies the model. In this example, Order Header and Order Details are combined so that they behave as a single fact. They are placed in their own folder and all relationships to them are deleted except the relationship between Order Header and Order Details. This is the only relationship that will matter after a model query subject is created and relationships attached to it.

showing the relationship between order header and order details

To decide where to specify relationships and determinants in the model, you must understand the impact of minimized SQL to your application.

For more information about relationships, determinants, and minimized SQL, see Analyzing models.