Monday, November 24, 2014

Micro-Startegy Interview Questions - Part 2

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:
http://2.bp.blogspot.com/-cheQsllB1mU/UC5UHx-M6GI/AAAAAAAAEFY/kZnuLuySNWU/s320/Conditional+Attribute.gif


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