Modellers should be careful to present a view that guides their users (especially QS users) away from building reports that violate these conditions. Techniques that can help:
· Use the star schema approach. The view that you expose to modelers should always be a set of stars or snowflakes, each in its own folder or namespace. (Refer to the FM User Guide section on Star Schema Grouping.)
· Never put two fact tables in the same folder or namespace.
· In a fact table query subject, avoid exposing any query items that are not facts (measures with an aggregation rule). If necessary, expose them as a separate model query subject that looks like a dimension.
· In each fact namespace, put only the dimensions that relate to it. Do not put dimensions anywhere else, such as in a common location.
· Always give conformed dimensions the same name in each namespace where they appear. That's the only way your users can tell that they are conformed.
· If two fact tables have conformed dimensions, but different levels of granularity for that dimension, include for each fact table only the relevant levels.
· If a dimension is based on a denormalized table, for each fact table create a model query that omits query items for levels below the level of granularity for that fact table.
For example, if inventory is only recorded at the month level, the time dimension for inventory should include years and months, but not days.
· Use naming and grouping conventions that make it clear what is a fact (which can be aggregated), what is a dimension identifier (unique, usable for grouping), and what is an attribute (anything else).
