Business users might not want Strategy to build any M:M Relationship tables while publishing the Intelligent Cube In-Memory due to the following reasons:
1) It distorts the actual relationship between a tuple of 3 or more attributes related to each other through M:M relationship in Project Schema by creating individual tables and joining through them when dataset is In-Memory. Live Connect provides true-er behavior reflecting the tuple data provided in the table.
2) If users want to provide and isolated M:M relationship between two attributes in the dataset, a separate table would be uploaded/provided anyways. Strategy should use this table to perform joins instead of building another table that just adds to memory footprint and degrade cube publication/incremental update performance by adding one more in-memory structure to update/manage.
Other Reasons:
1) M:M Relationships are always supported via a fact. Going forward, Strategy intend to not overload relationship concept with such special relationships through fact. 1:M/1:1 relationships are the only relationships that are true relationships independent on facts.
2) CSI/SQL Engine have capability to perform auto join via user uploaded tables.
3) CSI/SQL Engine would also have capability to define the scope of auto-join/filter propagation through fact tables using hierarchies.
Criteria:
1) For any cubes that are (re)published with either user defined/auto detected local M:M relationships OR inherited M:M relationships from Project Schema, there is no REL_A_B MANY_TO_MANY table created when publishing In-Memory cube.
2) Compared to a similar cube in previous release, memory foot print and cube publication performance improve proportional to the number/size of M:M relationships created while publishing the cube.
3) Unless a cube is republished, the existing M:M relationships that are part of cube cache do not get dropped during incremental update/unload/reload operations.
When a cube meeting the above criteria is published successfully, there will be some warning messages printed in the DSSErrors log, like the following:
2018-12-10 05:04:38.252 [HOST:env-123623laiouse1][SERVER:CastorServer][PID:29202][THR:139648007051008][Engine][Error] Attribute named Time Period with GUID 83505B4C40389AE45A9BDEA806DDB35E and Attribute named Date with GUID 3286D44B4572B4CAD29A80B0E88E789C from Intelligent Cube named Platform Analytics Cube with GUID 7C5CD53E11E529671FB700802FF7BD86 are mapped to project attributes and are 1:M relationship in the project but M:M relationship as per data in Intelligent Cube.
Strategy is using this message to warn the user the M:M relation table won't be created which could cause some potential performance/data issue. The user can fix the data in the WH if the expected relation should be 1:M. Or they can remove the relation definition if the actual relation is M:M. Though Strategy won't create M:M relationship table any more, the user can still upload their own separate relation table.
This feature has been implemented since Strategy 10.11. To utilize this feature,
The internal reference number for this is KB440215
