When modeling a database inside Strategy there are a few methods to try when mapping data. One is known as a transaction data model setup. This is where the main fact/driving table has a transaction key column which is mapped as a child of all the different real attributes for the different hierarchies present on the driving table. Examples of this include having an order ID attribute identifying individual orders while having it set as a child of customer, day, item and the other attributes that are not logically related. In order to be this sort of setup the relationships must exist as just having an order attribute with no relationships does not cause the same problems. Another common example comes from health care customers where the driving table has a visit/treatment style key which is a child of drug, doctor, patient, etc. An image of what this looks like in Strategy is below.
Notice how in this model all attributes have a path to each other through the shared Order child attribute.
This sort of data model is not supported in Strategy. Now to further explain "not supported" here means that some features of the Strategy product will be limited or completely non functional if this sort of data model is built and used in the product. This stems from how the engine generates SQL. Attribute only reports or logic will use attribute relationship paths to join. When all attributes are related this means joins will go down through the fact table rather than the attributes being treated as unrelated and cross joining. This means features such as preserve all lookup table elements or attribute only reports will be unable to give all attribute element combinations. In the example above it would be impossible to get all days with all items unless there was a valid order for the combination. Security filters will also produce invalid behavior as all attributes will be filtered by the security filter through a join to the fact table. It generally isn't desired to have the year attribute filtered by a customer region security filter (some customers such as health care providers like this behavior). Level dimensionality behavior can be inconsistent as level settings apply not just to the selected attributes but related attributes. This makes it difficult to ignore filters on some attributes while applying filters to others for level metrics. Transformations and non aggregatable metrics also have problems as they may try to use the order attribute for their logic rather than the desired day attribute. Keep in mind that the list of limitations and problems here is non-exhaustive.
Now sometimes reporting in an environment is very basic, attribute only focused and desires for all joins to occur through the fact table. In those scenarios it may be desired and beneficial to build this sort of data model. The restrictions apply to features that aren't used so don't present a problem for use of the product. Customers should still be informed that if their use expands in future that not all features will work.
If problems are encountered due to a transaction data model design that need to be resolved there are few rules and methods that can be used to address the problem.
The first note is that attributes which only share a fact table should not generally be related. In most scenarios the parents of the transaction key attribute are also present on the fact table so there is no need for relationships to and through this attribute and simply leaving it unrelated to anything will address the problems with behavior.
The next note is to have the customer verify if attributes would make sense if they were related outside of the fact table. Only in those scenarios do they have a valid logical relationship and should they be related inside of Strategy. This expands on what is covered in note one for scenarios where customers have single table warehouses, star schemas or just have multiple attributes on their fact table from a single hierarchy (for example if transaction, day and month are all on the fact table it is still valid to have a relationship between day and month).
The final note covers the scenario where relationships are needed explicitly to order for some attributes due to a lack of presence on the fact table or through specific relationship needs. In this scenario multiple copies of the transaction attribute can be created. One copy is made per each different unrelated hierarchy to be the lowest level child in those hierarchies. The main transaction attribute should be left unrelated to all hierarchies and other attributes. The copies can be hidden so that users only know and can use a single transaction attribute while the others cover necessary joins for the engine.
In summary the transaction data model is a semi common setup to come across and the main point to stress is that it has limitations. This doesn't mean it can't be used but merely that not all features are able to function with it. Workarounds exist to change the data model to a more supported one so that features can be used but the full extent of what changes can be extensive.
