Microstrategy Blog

I remember it well. Long night spent trying to figure out how best to line metrics up next to each other. Hours spend trying to figure out if it’s more work just creating you’re own logical table to solve that stupid cross join problem that won’t go away. I’m reticent to consult the MicroStrategy web site because it really does just feel like I’m copping out…

If you have a static warehouse that the designers are committed to, what else is your option?

Late night..

Addendum: You know sometimes I forget that SQL optimization is just that…optimization. I can some time putting together a quality query that’s going to return data on a specific products ships and returns. Let’s assume that each of these products have a distinct way of being tracked. I might throw together a hand done query that populates the list of these specific reference numbers from the ship table so that I can do a left join against the shipping data so I can see specific returns against the specific ships, and then aggregate those solutions, but did you see what I just did? I went through the trouble of matching thousands of records against each other…and for what? So that I can later aggregate the data with some sort of group by.

Enter SQL optimization. Solves the problem in a quicker way that I probably wouldn’t have crossed my mind since it works in a linear fashion.

1. Get ships.
2. Get returns.
3. Left join ships to returns based on unique ID.
4. Count records in relevant columns.
5. Group by necessary items.

But…why is the detail necessary?

MicroStrategy fixes.

(
select a12.date,
count(a11.sales_number) SALES_COUNT
from sales a11
where (a11.item_desc = ‘widget’)
group by
a11.date
) pa11

full outer join

(
select a11.date,
count(a11.rma_number) RMA_COUNT
from rma a11)
where (a11.item_desc = ‘widget’)
group by
a11.date
) pa12

on
(pa11.date = pa12.date)

Makes much more sense. Why join early when all you care about is the aggregate…join on the aggregate!

Duh.

Notes From an Install

Starting Fresh.

I’m creating a Demo MicroStrategy Development install for the new place. The ultimate goal, I think is to get away from the in house development, which can be tedious, and move towards the fully SOA solution.

I already have SQL Development Server on my laptop, so I’m going to be using that as the Metadata/Statistics/History Database. I have to fun of bridging to a Teradata Database for the actual project…which is going to be interesting, considering I’ve always used SQL normalized data warehouses, so this will be a welcome change.

I’m using Windows 7 on a Dell Latitude E4300 Laptop, P9600 @ 2.53 gHz and 4 gigs of RAM. So, it should be fine for Demo Purposes.

First off, I forgot how quick the install process is (all things considered), as well as how simple the interface is for defining your various data sources. Make sure also to install the Tutorial if you’re new to the process. You can learn more from the Tutorial and Analytics projects than any manual that MicroStrategy provides, at least for me. Based on my new job functions, I’m becoming increasingly interested in the statistical modeling capabilities of MicroStrategy.

As a side note: if you want to waste some time, and you have an error on your Intelligence Server when you try to start it that states:

“Failed to start service Error Code: -1 Error Message: StartUpManager::StartUpManager():LoadServerDef failed. Return Code: 0×80041404′”

Here’s a hint for you…maybe you’re like me, and you gave the ODBC access to your MetaData read only…which is stupid. I admit it.

On with the development!! I’ll post as I see fit.

Notes From an Install

No…I’m not there.

I am, however, getting late night text messages about how awesome the bars are. Thanks guys.

MicroStrategy World

The “avg” function is MicroStrategy has caused me problems in the past. It’s not that “avg” does anything wrong…it just doesn’t necessarily provide the correct subtotals to the end user, depending on the end user requirements.

Here’s the report output that examine all of the different ways average can function.

Now we’ll examine these metrics left to right.

This first one is your true “Avg” metric. Here’s the SQL that is sent through when you query the Warehouse.

SELECT
- ID,
- AVG(VALUE)
FROM FACT_VALUE
GROUP BY ID


Simple enough…but now say you want the “total” average as related to these groups. In the metric definition if you select “avg” as the aggregation type, you’ll notice that the average in the subtotal, is simply the average of the averages (following me?). Because you’re returning the data already at the aggregated level, the system doesn’t know what’s driving t in the background.

The second metric is actually the “weighted average” for our purposes. This metric is actually defined as the SUM(VALUE)/COUNT(VALUE), with the Smart Metric Enabled on your metric creation. The subtotal of this metric is actually the true average of all of the values, not the average of the average.

The columns that follow prove the logic out. You can see that the sum/count is the “more” correct way to calculate average. Keep this in mind when designing your metrics.

Metrics, Tips and Tricks avg, metric

At this point I think that I’ve worked with enough instances and installations of MicroStrategy to know bad and good ideas when I see them. The most common irritation that I’ve come across is this idea that MicroStrategy is where all of the heavy lifting of the parsing and hierarchies takes place. While MicroStrategy can do the heavy lifting, this isn’t always ideal.

For instance:

I worked with a client whose Accounting General Ledger was your basic structure. Let’s say the account structure was thus:

Revenue accounts were 5000 – 5999
Cost of Goods Sold were 6000 – 6999
Expenses were 7000 – 9999

Now, in a MicroStrategy environment, one could create custom groups so that these GL accounts could be properly categorized that defines ranges, but that’s seldom the best way to go about it.

I have predefined categories that I know that I want postage as an expense to roll into. Postage -> Shipping ->Expense.

I create a table called GL_GROUP, which is the next level up of the hierarchy, and added a column to the GL_ACCOUNT able which was a reference to this new table. Here’s the GL_ACCOUNT table.

GL_ACCOUNT_ID	GL_ACCOUNT_DESC	GL_GROUP_ID
5001	Cat A Sales
5002	Cat B Sales
8001	Corp Salaries
8002	Admin Salaries
8003	Sales Commission

Note that the GL_GROUP_ID Column is currently Null.

The GL_GROUP table looks like this.

GL_GROUP_ID	GL_GROUP_DESC	GL_LOW	GL_HIGH
500	General Revenue	5000	5499
550	Misc Revenue	5500	5999
600	Manufacturing	6000	6999
700	Administration	7000	7999
800	Salaries	8000	8499

The script that accompanies this table is as such:

UPDATE lugl
SET lugl.GL_GROUP_ID=lug.GL_GROUP_ID
FROM GL_ACCOUNT lugl
JOIN
GL_GROUP lug
ON
lugl.GL_ACCOUNT_ID between lugg.GL_LOW AND lug.GL_HIGH

This has been incorporated into the ETL process so that as any accounts are added and they fall into the appropriate range (the Accounting people have to be on top of good logic on their side). Once complete, you get this.

GL_ACCOUNT_ID	GL_ACCOUNT_DESC	GL_GROUP_ID
5001	Cat A Sales	500
5002	Cat B Sales	500
8001	Corp Salaries	800
8002	Admin Salaries	800
8003	Sales Commission	800

Now, pull the GL_GROUP table into the Warehouse Catalog, add a GL_GROUP attribute, and modify your GL_ACCOUNT attribute so that it’s the child of GL_GROUP as a one-to-many. Now some of you will look at this and just go “Duh”, but you’d be surprised not only how many MicroStrategy installations I’ve come across where people have made Custom Groups to deal with this (because of the “ranges” of accounts). Custom Groups slow things down.

In short, let the Warehouse do the heavy lifting during your ETL process…and let MicroStrategy be a clean and streamlined as possible when it pushes the SQL through. MicroStrategy can solve this problem alone. But should it? I think not.

All Things Data, Data Warehouse, Things I Learned