How to create a
conditional attribute in Micro Strategy Desktop
A user may want to create an
attribute with an alternating expression depending on a certain condition, a
conditional attribute. This condition may be implemented through an Apply
Simple statement such as the following:
Types of Attributes
Simple
A simple attribute is made up of one
or more expressions. With a simple attribute definition, you can define an
attribute as a column, constant, or simple expression.
Implicit Attributes
An implicit attribute is a virtual or
constant attribute that does not physically exist in the database because it is
created at the application level. The implicit attribute has its own
expression.
Derived Attributes
A derived attribute has its value
determined by an expression which combines two or more columns in a database to
create a new column.
Compound Key Attribute
A compound key attribute is an
attribute whose primary key is made up by the combination of two or more
columns.
What is a Implicit
Attribute?
An implicit
attribute is a virtual or constant attribute that does not physically exist in
the database because it is created at the application level. The implicit
attribute has its own expression.
What is a
joint child?
A joint child is Microstrategy way of handling Composite Keys. Composite keys are constituted of two or more columns which together act as unique identifier. To handle this case in Microstrategy we make this set of columns, constituting composite keys, as joint child.
What are attribute
roles?
A user defines two attributes that have the same definition but play different roles in the business model. In this example, attribute Origin Airport and Destination Airport are defined using the same Lookup Table and Column (Airport_ID). Both attributes share the same forms, or information about them (Description, Location, etc.). In the fact table, however, a separate column exists for each of their roles (Origin_Airport_ID and Destination_Airport_ID).
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?
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 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.
How are the
drilling options for an attribute decided?
Based on relation
between attributes, hierarchies and their drilling configuration
What are the two
types of Hierarchies?
System hierarchy:
It contains all the project attributes and its available browse paths and is
based on relation between attributes.
User defined
Hierarchy: Custom grouping of attributes and define their browse paths.
No comments:
Post a Comment