Logical Views to specify an outer join between two attribute lookup tables when only attributes are on a report

Apart from using the VLDB properties to create the left outer join, article describes how to use the Logical View to specify an outer join between two attribute lookup tables when only attributes are on a report. This method exists as attribute only outer joins will not be generated on their own by the MicroStrategy SQL engine. This is because they are only necessary with ragged/unbalanced hierarchies which are not supported as null attribute IDs are not supported (parent elements with no child elements or child elements with no parents).

Brief instructions are provided using the example below.

Consider, two attributes: Parent01 and Child01 have a parent-child relationship. Their Lookup tables are defined, as follows

Parent01	Child01

Note that although there are 4 ID values for the attribute Parent01, there is no defined relationship for the Parent01 element p4 (ID=4) in the Lookup table for attribute Child01. Placing both attributes on a report will result in the following SQL and data returned. Parent01's element p4 will not be returned. This is known as a ragged hierarchy and is not supported in MicroStrategy.

SQL	Data Returned
select a12.parent01_ID parent01_ID, a13.parent01_DESC parent01_DESC, a12.child01_ID child01_ID, a12.child01_ID child01_ID0 from child01 a12 join parent01 a13 on (a12.parent01_ID = a13.parent01_ID)

To overcome this issue, create a Logical View with the following SQL. Note the Left Outer Join.

SQL	Logical View Definition
select a12.parent01_ID parent01_ID, a12.parent01_DESC parent01_DESC, a11.child01_ID child01_ID, a11.child01_DESC child01_DESC from parent01 a12 left outer join child01 a11 on (a11.parent01_ID = a12.parent01_ID)

Modify the attribute Child01 to include the new Logical View as a source table and redefine a relationship to attribute Parent01 using the new Logical View.

Add Source Table	Add Relationship

Executing the same report will now return all elements for Attribute Parent01.

SQL	Data Returned
select /* RRR01 / a12.parent01_ID parent01_ID, a12.child01_ID child01_ID from (select a12.parent01_ID parent01_ID, a12.parent01_DESC parent01_DESC, a11.child01_ID child01_ID, a11.child01_DESC child01_DESC from parent01 a12 left outer join* child01 a11 on (a11.parent01_ID = a12.parent01_ID)) a12

Comments

MicroStrategy URL API Parameters

MicroStrategy URL Structure The following table summarizes the root URL structure used for every request to MicroStrategy Web. Environment Main Application URL Administration URL J2EE http://webserver/MicroStrategy/servlet/mstrWeb http://webserver/MicroStrategy/servlet/mstrWebAdmin .NET http://webserver/MicroStrategy/asp/Main.aspx http://webserver/MicroStrategy/asp/Admin.aspx Every request sent to MicroStrategy Web calls a central controller. Parameters are appended to Main.aspx or mstrWeb (in a .NET and J2EE environment, respectively) to indicate to the controller how the request should be internally forwarded and handled. The following examples show a URL for accessing a MicroStrategy folder when the user does not have an existing session. The URL contains not only the parameters needed to connect to MicroStrategy Web, but also the parameters needed to log on and create a session. J2EE environment: <a href="http:...

MicroStrategy Developer Preferences options are expanded so big that some options are being cutoff. Show the hidden objects in the Microstrategy developer MicroStrategy Developer Preferences options are expanded so big that some options are being cut off. The steps below given in the MSTR article may not work. This can be simple handled by using the steps below: In the Microstrategy Developer go to Tools -> Preferences (Not my prefernces :) ) Under Developer category -> select Browsing on the browsing tab you see all the options like below: 3. Now using the mouse place the cursor on text box of 10000 which is next to 'Maximum number of monitoring objects displayed per page. 4. Then Hit Tab on Keyboard and hit another Tab on keyboard 5. Then press the space or down arrow on keyboard and click on OK or Enter. That will show the hidden objects in the Microstrategy developer Normal Version ...

Microstrategy Dossiers explained

Microstrategy Dossiers With the release of MicroStrategy 10.9, we’ve taken a leap forward in our dashboarding capabilities by simplifying the user experience, adding storytelling, and collaboration.MSTR has evolved dashboards to the point that they are more than dashboards - they are interactive, collaborative analytic stories . Ultimately, it was time to go beyond dashboards, both in concept and in name, and so the've renamed VI dashboards to ‘ dossiers ’. Dossiers can be created by using the new Desktop product or Workstation or simply from the Web interface which replaces Visual Insights. All the existing visual Insights dashboards will be converted to Dossiers With MicroStrategy 10.9, there was an active focus on making it easier to build dashboards for the widest audience of end users. To achieve this, some key new capabilities were added that make it easier to author, read, interact and collaborate on dashboards ...

Creates a report delivery schedule in Microstrategy

mstrio – Python and R wrappers for the MicroStrategy

mstrio – Python and R wrappers for the MicroStrategy REST APIs Connecting to MicroStrategy Create a connection to the Intelligence Server using Connection() and  connect() in Python and R, respectively. Required arguments for the   Connection()  function are the URL for the MicroStrategy REST API server, MicroStrategy Intelligence Server username and password, as well as the MicroStrategy project name. By default, the  connect()  function anticipates your MicroStrategy Intelligence Server username and password. LDAP authentication is also supported. Use the optional argument  login_mode=16  in the  connect()  function for LDAP authentication. Extract data from cubes and reports To extract data from MicroStrategy cubes and reports, use the get_cube()  and  get_report() functions. Use...

Microstrategy "Error type: Odbc error. Odbc operation attempted

"Error type: Odbc error. Odbc operation attempted: SQLExecDirect. [HYT00:0: on SQLHANDLE] [MicroStrategy][ODBC Oracle Wire Protocol driver]Timeout expired" is shown when executing reports from Web When users are trying to execute some reports in MicroStrategy web in particular, they may receive the Error “SQL Generation Complete Index out of range” and “Timeout expired” error as shown below: Possible Causes: One possible cause is that the MicroStrategy Intelligence Server using a cached database connection that was already dropped by the RDBMS. To resolve this: Admin should delete the database connection caches and create a new DSNs in case they are sharing DSNs to connect to different databases. In addition, change the settings for the ‘Connection lifetime’ and the ‘Connection idle time out’. Follow the steps below to perform the mentioned changes and verify the report after each step and some of the settings require i-server r...

Star schemas and aggregate (or summary) fact tables Aggregate tables can further improve query performance by reducing the number of rows over which higher-level metrics must be aggregated. However, the use of aggregate tables with dimension tables is not a valid physical modeling strategy. Whenever aggregation is performed over fact data, it is a general requirement that tables joined to the fact table must be at the same attribute level or at a higher level. If the auxiliary table is at a lower level, fact rows will be replicated prior to aggregation and this will result in inflated metric values (also known as "multiple counting"). With the above Time dimension table, a fact table at the level of Day functions correctly because there is exactly one row in DIM_TIME for each day. To aggregate the facts to the level of Quarter, it is valid to join the fact table to the dimension table and group by the quarter ID from the dimension table. Sql select DT...

Best practices for scheduling jobs and administrative tasks in Microstrategy

Best practices for scheduling jobs and administrative tasks Below are the recommended best practices when scheduling jobs and administrative tasks in MSTR: Executing simultaneous reports can strain system resources. If you have many reports or tasks that need to be executed on the same time-based schedule, consider creating several similar schedules that trigger 15 minutes apart. For example, one schedule triggers at 8 AM every Monday, and another triggers at 8:15 AM. To prevent users from scheduling many simultaneous reports, you can prevent users from scheduling jobs using a schedule by editing the schedule’s Access Control List (ACL). To do this, in the Schedule Manager, right-click the schedule and select Properties , then select the Security tab in the Properties dialog box, and make sure that only users who can use the schedule have Modify or Full Control access to the schedule. Establish reasonable limits on how many scheduled jobs are allowed. For details on ...

Create an alert-based subscription in MicroStrategy Distribution Services

Create an alert-based subscription in MicroStrategy Distribution Services on Web Subscription to a report or Report Services document which will be executed when a certain conditional threshold is met based on another executing report. For example, a scheduled report executes which shows the Revenue by day for the past week. If the Revenue on any one day falls below a certain value, a subscription to another report or Report Services document can be triggered and delivered to a recipient. An alert based subscription can only be created directly on a report; however, another report or Report Services document can be delivered when the alert based subscription is triggered. Note: you need a grid report to create an alert and you cannot create if you want to create on a document with text boxes. The following example will walk through the basic steps on how to setup a subscription based on an alert like this: Follow the brief steps bel...

Case functions Microstrategy

Ca se functions Microstrategy Case functions return specified data in a SQL query based on the evaluation of user-defined conditions. In general, a user specifies a list of conditions and corresponding return values. Case This function evaluates multiple expressions until a condition is determined to be true, then returns a corresponding value. If all conditions are false, a default value is returned. Case can be used for categorizing data based on multiple conditions. This is a single-value function. Syntax Case ( Condition1 , ReturnValue1 , Condition2 , ReturnValue2 ,..., DefaultValue ) Example Case(([Total Revenue] < 300000), 0, ([Total Revenue] < 600000), 1, 2) sum(Case (Day@DESC in (“Sat”,”Sun”), Sales, 0) {~+} Sum(Case(Category@DESC In("Books","Electronics"),Revenue,0)){~+} CaseV (case vector) CaseV evaluates a single metric and returns different values according to the results. It can be used to perfo...

Microstrategy Analytics

Search This Blog