The Disallow partially or completely the fact entry level setting within the Fact Editor is like a lock which prevents a fact from being reported at a specific level. The setting prevents unnecessary joins to lookup tables. The following examples describe instances in which disallowing a fact entry level can prove useful.
Disallowing a fact to be extended to a level lower than the fact’s entry level due to unnecessary complexity and the cost of analyzing fact data at such a level is a common use for this feature. If a fact is stored at a level that is counterproductive to a query, such as data that is stored at the Minute or Second level, you can disallow the lower levels. For example, if you have three years’ worth of data, querying at the Minute or Second level consumes too many resources and returns extensive data. With a disallow in place, if you create a report and attempt to include the fact at the Minute or Second level, an error is returned, indicating that the report cannot be run at that level.
Consider a schema containing three dimensions: Geography, Time, and Product. Suppose you create a fact called Sales at the Item level in the Product dimension and a metric called Sales as the sum of the Sales fact. When you create a report containing the Month attribute and the Sales metric, the Analytical Engine does a dynamic cross-join and evaluates the report. To explicitly disallow an extension of the Sales fact to the Time dimension, you would use the Disallow partially or completely the fact entry level setting and select the lowest attribute in the Time dimension such as Day. This option is set in the step immediately after Defining a join on fact tables using table relations of the procedure to create a fact extension above. After updating the schema and re-executing the report, the report fails because the disallow setting now prevents the cross-joins between the lookup tables and fact tables. This setting, however, does not affect normal joins.
In the previous example, for the Sales fact, assume you specify an extension to the Month attribute and also disallow extension to Year which is a parent of the extended attribute, Month. If you execute the report containing the Year attribute and Sales metric, the report runs successfully. In this case, the engine sorts the extension conditions specified in some order and calculates the report based on the sorted order of extensions. This is not an expected design condition, although the engine returns a valid SQL. It is advisable to avoid fact definitions that contain contradictory extension definitions.
The Disallow the fact entry level setting applies only to attributes that can be considered as extended attributes. For example, you create a report that contains the attributes Subcategory and Item and the Revenue metric, which is defined as sum of the Revenue fact. You now disallow an extension on the Revenue fact for the Item attribute and update the schema. If you re-execute the report, you can still see Revenue by Item. This implies that the fact extension has not been disallowed. This is because Revenue exists at the same level as Item in the MicroStrategy Tutorial project. So you encounter only normal joins and no extensions. There must be a valid reason to disallow reporting a fact at a certain level. In this case, disallowing the Revenue fact at the level it is stored at in the data warehouse does not make logical sense.