Wyn Enterprise User Guide
- An Introduction to Wyn Enterprise
- Document Portal for End Users
- Using Report Designer
- Create Static Report
- Create Tabular Report
- Create Parameterized Report
- Create Master-Detail Report
- Create Pivot Report
- Create Report with Chart
- Styles and Themes
- Expression Editor
- Report Templates
- Working with Dashboards
- Dashboard Designer
- Selecting a Dataset
- Data Attributes
- Dashboard Scenarios
- Charts and KPIs
- Calc Charts
- Containers and Components
- Dashboard Appearance
- Preview Dashboard
- Export Dashboard
- Data Analysis and Interactivity
- View and Manage Dashboards
- Governing Data and Resources
- Create Data Source
- Data Source Connections
- Create Dataset
- Create Semantic Model
- Secure Data Management
- Create Floor Plan
- Upload Resources
- Using Dashboard Designer
- Section 508 Compliance
Wyn Enterprise: Add a Relation
A relation item in a model describes the relationships between entities. To modify a model relation, select a semantic model from the list of available semantic model and click the Edit icon. To add a new relation, click the Add button in the Relations section.
In the Add Relation Properties, enter the name and description of the new relation.
In the Relations section, set the target entity by selecting it from the drop-down list. Then you should add a Source Column and a Target Column that appear below.
Click the Add button. A newly added relation will appear in the list of relations of the semantic model's entity.
Relation cardinality dictates how relations are generated when you create a logical model, and how they are used to generate underlying SQL JOIN queries when you run reports.
When you add relations between entities, there are rules to determine cardinality. There are four ways that entities can relate:
- One: One-to-one
- Many: Many-to-many
- OptionalOne: One-to-zero or one
- OptionalMany: Many-to-zero or more If you add relations between entity A (from table A) and entity B (from table B) using the corresponding sets of tables in AC and BC, the rules for determining cardinality are as follows.
Adding relation AB to entity A
- If there is a unique constraint on table B that is nullable and exactly matches the columns in BC: OptionalOne.
- If there is a unique constraint on table B that is not nullable and exactly matches the columns in BC: One.
- Otherwise: OptionalMany. (You cannot use Many in creating relations, but you can set it explicitly.)
Adding relation BA to entity B
- If there is no unique constraint on table A that matches the columns in AC: OptionalMany.
- If there is a unique constraint on table B that matches the columns in BC, and one of those columns is nullable: OptionalOne.
- If there is a unique constraint on table B that matches the columns in BC, and none of those columns is nullable: One.
We can add a relation between the Album and Artist tables using the ArtistID column. Assuming this relation does not exist in the database yet, if we add the relation from the Album entity, we get an Album-to-Artist relation with OptionalOne cardinality and an Artist-to-Album relation with OptionalMany cardinality.
SQL JOIN Types
The role cardinality is not taken into account when determining what JOIN type to use. The relation in the data source controls the behavior.
- If the relation belongs to the table that the query joins to, then it uses a LEFT JOIN.
- If there is at least one column in the relation that accepts a null value, then it uses a LEFT OUTER JOIN.
- Otherwise, it uses an INNER JOIN.
Basically, if it accepts null values, it uses outer joins, otherwise it uses inner joins.
The Album table has a foreign key constraint linked with the Artist table, there is a relation created for it, and it belongs to the Album table. So long as Album.ArtistID does not accept null, then for queries joining the Album table to the Artist table, we use an INNER JOIN, but for queries joining the Artist table to the Album table, we use a LEFT JOIN. However, if Album.ArtistID is nullable, then even in the case of queries joining the Album table to the Artist table, we use a LEFT OUTER JOIN.
Consider relations based on foreign constraints between Playlist, Track and PlaylistTrack tables via PlaylistID and TrackID. The relations belong to the PlaylistTrack table as they refer to Playlist and Track. Assume for this purpose that CollapseInRelations is not set for PlaylistTrack.
If you drop Playlist.Name and Track.Name to create a table, then the query tree looks like this:
PlaylistTrack > Playlists > Tracks
In both cases, it uses an INNER JOIN, as both relations belong to the table (PlaylistTrack) from which the query pulls.
In the case of the Album and Artist tables, the relation connects an Album to an Artist by the ArtistID. So you can drop the Artist.Name attribute and a "Total Albums" aggregate to create a table. If you drop the Name attribute first, then the query looks like this:
Artist > Album
In this case, it uses a LEFT OUTER JOIN because the relation belongs to the table (Album) from which the query pulls.