KB9731: When should attribute relationships be modeled as separate attributes in a parent-child relationship and when should they be modeled as forms of the same attribute in MicroStrategy 9.4.x-10.x?

Attribute forms are intended as an alternate description for an attribute. Attributes related in a hierarchy generally allow more flexible data modeling.
 
Normally, it is preferable to use separate attributes that are related hierarchically (that is, parent-child relationships) for the following reasons:

• Attributes that exist in a hierarchical relationship can appear independently of each other on a report. If 'Item' and 'Item Category' are modeled as separate attributes, reports may then be designed to report on individual items or whole categories. If 'Item Category' is considered a description (form) of 'Item', it becomes impossible to report on 'Item Category'.
• Attribute forms are not available as metric dimensionality settings. In order to aggregate data at a particular attribute level, that attribute must exist as an attribute. If the attribute is modeled as an attribute form instead, it is possible to aggregate only at the level of the attribute containing the form.
• Attribute lookup tables are joined to other tables only on the basis of the attribute ID. Attribute forms may never have an ID independent of the attributes that own them.

If these data modeling features are not required for a particular relationship, then an attribute form can legitimately be used. For example, a customer or employee attribute may have separate forms for ID, full name, first name, and last name. Since one will typically be reporting on customers or employees, there's no need to have separate attributes for each of these forms.
 
However, if it's desired to aggregate at the level of last name, for instance, then a separate attribute will be required. If a user creates a report in the Strategy Tutorial project displaying 'Customer' (Last Name form only) and 'Revenue', and filtering on Last Name Begins with "Sm," the report will show the following results:
 

 
Note that the results are not aggregated at the level of the customer's last name, but rather at the level of Customer. If the report level were Customer Last Name, there would be only one entry for each distinct last name. If it is desired to create a report showing total revenue for distinct last names, Customer Last Name must exist as its own attribute.
 
If an attribute's lookup table contains numerous columns of descriptive information, such as first name, last name, zip code, income bracket, etc., users may think it is logical to view all of these as forms of the attribute since they come from the same table. As demonstrated above, however, this imposes serious constraints on the ability to create reports at multiple dimensions.
 
Users should always be careful with attributes containing more than four or five forms. If many or most attributes in a schema have large numbers of forms, it is an indicator that several aspects of the schema design may need to be reconsidered.
 
Attribute forms are not appropriate under the following circumstances:

• When the attribute must be used as an aggregation level (metric dimensionality). For example, customer and state: if a user wishes to calculate sales totals by the states in which customers live, state should be a separate attribute as a parent (or grandparent, and so on) of customer.
• When the attributes exist in a one-to-many or many-to-many relationship. For example, customer status: Presumably, each status will apply to several customers. Modeling status as a form of customer makes it always subordinate to customer, which may impose unnecessary limits on reporting options.

Attribute forms are appropriate when the following is true:

• When an additional description is needed for an attribute but the descriptor will not be needed for data aggregation or report organization.