MicroStrategy Business Objects Cognos comparision

Single Metadata – Object definition is stored in a database (called metadata), How easy is changes to be integrated made from one interface to another.

64 Bit support – 32 bit system can’t address more than 4 GB of system space. All non-Windows OS are available in 64 bit for ages. Windows also got it in June 2005, but BI vendor should be able to support 64 bit OS.

Scalability – Any calculation performed in database is the best and fast and let very small load on the BI architecture. But not all BI vendors let it happen.

Reusable Objects – Make once use zillion times.

Objects Version Control – Ability to have different version of same (schema) objects.

WYSIWYG – Look and feel of what you created and finally how it looks.

Security – Object, User security.

Personalization – Single report but show different output to different users.

Manual fine-tuning SQL – Easily making changes to generated SQL.

Ease of SQL Generation – Make Schema object and system and forget about the right SQL generation.

MS Office integration – Run report directly from Word, Excel or Powerpoint.

(There is some bug with HTML parser on Blogger.com. Please scroll down for the comparison table. Do write into your comments. I'd update/add more information accordingly)

	MicroStrategy	Business Objects	Cognos
Single Metadata	Yes	No	No
64 Bit support	Very Good	Good	Good
Scalability	Excellent	Good	Very Good
Reusable bjects	Excellent	Good	Good
Objects Version Control	Very Bad	Excellent	Very Good
WYSIWYG	Very Good	Very Good	Very Good
Security	Very Good	Good	Very Good
Personalization	Very Good	Good	Bad
Manual fine-tuning SQL	Good	Excellent	Excellent
Ease of SQL generation	Excellent	Very Good	Very Good
MS Office integration	Very Good	Bad	Good
Learning Curve	Bad	Very Good	Very Good
Number of Clients	10000	42000	23000
Number of Employees	2000	NA	3500
Cost of License	$$$$$	$$	$$$
Support Cost	$$$$$	$$$	$$$
Average Pay (USD)##	83000	78000	79000
Job Security	Good	Excellent	Very Good
Cost of License	$$$$$	$$	$$$
Support Cost	$$$$$	$$$	$$$

## - indeed.com

Heros of this blog

There are two heroes of this blog, whom I've mentioned a couple of time. They finally arrived on this blog and left some comments. Actually in Jan 2008.

Gurvinder Singh Chhatwal (Project Manager of MicroStrategy-QA project in Cybage, Pune)
"At least a MILLION times people around you, who have worked and lived with you have told you what an IDIOT you are. But seems you still fail to understand.
Pity on you."

Paramjeet Singh Sidhu (Project Lead of MicroStrategy-QA project in Cybage, Pune)
"No wonder you write all bullshit about the people you work with because they all know how sick your thoughts and you were (seems like you still are). Anywayz, you and your fantasies go on and on.
May god help you."
---------
People like you give me good learning. I'll not forget Cybage because of people like you. I owe you this. I pity having worked under you guys. I don't think I'll ever get any manager like you and pray to god that no one in this world gets it. and who was/is sick is known to persons concerned. May god help both of you. Last but not least, thanks for stopping by on the blog.

MicroStrategy Intelligence Server query flow

The main components of MicroStrategy Intelligence Server are:

1. Intelligence server bus
2. Intelligent Cubes server
3. Communication layers for the metadata and data warehouse
4. SQL Generation Engine
5. Query Engine
6. Analytical Engine

The query flow below describes the primary functions of each component.

MicroStrategy Intelligence Server query flow

1. The MicroStrategy Intelligence Server receives a report request from any interface.
2. The request is passed to the Intelligence Server bus, which coordinates all the tasks necessary to execute the report.
3. Intelligence Server first checks the cache to see whether the report results are already there. The report results will already be in cache if another user or a schedule previously ran the report. If a cache exists, Intelligence Server skips directly to step 9.
4. If no valid cache exists for the report, the Intelligence Server bus obtains the report definition and application objects from the metadata.
5. The bus sends this information to the SQL Generation Engine. The SQL Generation Engine creates the optimized SQL, specific to the database being used. The SQL passes are then returned to the bus.
6. The bus sends the SQL to the Query Engine. The Query Engine runs the SQL against the data warehouse and the report results are returned to the bus.
7. The Intelligence Server bus invokes the Analytical Engine. Additional calculations are performed as necessary (when the calculation is unavailable in the database being used), and the Analytical Engine formats the results. The results are returned to the Intelligence Server bus.
8. Depending on the analytical complexity of the report, the results might be passed back to the SQL Generation Engine for further processing by the database. Only MicroStrategy can provide this collaborative analysis with the database, resulting in forms of queries that can only be solved by MicroStrategy. In this case, steps 4–6 are repeated until the final report results are obtained. Finally, the formatted results are returned to the client communication layer.
9. The Intelligence Server passes the formatted results back to the client.

----------------------------------------------
I had this article for around 2+ years in my archives. Most probably this is an internal MicroStrategy document. If you are © owner and want me to pull this down, please post a comment. There is a link to post comment. I come to know about any comment on blog as soon as it happens. If you can help me with the origin/source of this document, please help me. This is the first post on this blog which is not straight from heart, but hope I don't deviate from it.

Tiers in MicroStrategy

I have heard people saying web is three tier connection in several interview and desktop (with I-server) is a two tier connection. Such answers about tiers really gives me tears. [:)]. You are hear reading this page just mean that you are too lazy to read the MicroStrategy PDFs. Anyways here is the information about various tiers.

Anything that doesn't requires I-server is 2 tier. One can have two tier connection not only with Access but also SQL Server, Oracle, Netizza, Teradata, etc, In fact with any damn database. In such case, Desktop and Metadata/Database are two tires. DSN is important in this case. In fact that become heart in 2 tier. You never need to use Configuration Manager in case of a 2 tier connection.

Any time you use configuration manager to connect I-Server to Metadata (obviously with DSN) is a three tier. In this case the tiers are, Desktop - I-Server - Metadata/Database.

Any time you use Web is a 4 tier architecture. And tiers are as follows.
Web Browser - Web Server - I-Server - Metadata/Database.

A 5 tier architecture is also possible. There are various vendors who sell installable reporting tool based on MicroStrategy architecture. In this case the 5th tier sits between Web Browser and Server.

Version control in MicroStrategy

MicroStrategy doesn't support Versioning. BTW, There are two types of versioning in MicroStrategy. Source control (what I'm taking about over here) and Slowly changing dimension (SCD). Lots of clients have put requests to MicroStrategy to have this feature of version control for schema object or at least attributes. In short the answer for this question is NO and I would never want MicroStrategy to have this features. Such a feature request is only idea that can come from bad MicroStrategy practice. Why in this world, do you want to have two definition. If a change in attribute breaks a report or sql goes haywire, one should rather fix this (that why it is job of MicroStrategy Architect). Such a feature would lead to lots of useless trial-n-error stuff in MicroStrategy. If you know any company who is behind this feature request, please post the name over here.

FYI, as per document ID (TN4100-800-0349), A current enhancement request exists for this functionality. Contact MicroStrategy Technical Support for the latest update of this request.

This would be a good feature for nuts in MicroStrategy and will give sane people hard time.

Update 13 Feb 2009

Cognos supports this feature. But one can't use different object(s) from different set of version. :-(

Difference between accessing fact table and lookup table in Grouping option of Metric creation

There is another important difference between accessing a fact table and a lookup table. If a value, such as April sales, is missing from a fact table, the row still exists in the table and is reported as null or zero. If that same value is missing in a lookup table, the April row does not exist. The previous or next value (March or May) is reported, depending on whether the level is set to beginning or ending value.

---
Please post your comment on this.

Can't wait for papa john

I love Pizzas. When I arrived at Bangalore, I used to have 2-3 a week. I had this (bad) habit for around till mom came over here in month of Dec and now Papa John is coming to India soon. Can't wait for Papa.

And ManU has defeated Arsenal and they have clear 6 pt lead from Chelsea. Wanna see them lose the title [:D]

What's factless fact

I have been reading about factless fact table for quite some time and had assumption that bridge table in case of M-M relationship was "the" factless. But while having a knowledge sharing session I was given a total new definition. That was convincing but unbelievable. Though bridge table is actually a factless fact table but not as per Kimball.

A factless fact table is table that doesn't have fact at all. They may consist of nothing but keys. There are tow types of factless fact table. 1-> event 2-> coverage.

Take an example of a factless fact table that records an event. Many event-tracking tables in dimensional data warehouses turn out to be factless. Take an example of tracking student attendance. Imagine that you have a modern student tracking system that detects each student attendance event each day. When the student walks through the door into the lecture, a record is generated.

One can easily list the dimensions surrounding the student attendance event.
Date: one record in this dimension for each day on the calendar
Student: one record in this dimension for each student
Course: one record in this dimension for each course taught each semester
Teacher: one record in this dimension for each teacher
Facility: one record in this dimension for each room, laboratory, or athletic field

The only problem is that there is no obvious fact to record each time a student attends a lecture or suits up for physical education. Tangible facts such as the grade for the course don't belong in this fact table. This fact table represents the student attendance process, not the semester grading process or even the midterm exam process. Actually, this fact table consisting only of keys is a perfectly good fact table and probably ought to be left as is

A second kind of factless fact table is called a coverage table. Coverage tables are frequently needed when a primary fact table in a dimensional data warehouse is sparse. Take simple sales fact table that records the sales of products in stores on particular days under each promotion condition. The sales fact table does answer many interesting questions but cannot answer questions about things that didn't happen. For instance, it cannot answer the question, "Which products were on promotion that didn't sell?" because it contains only the records of products that did sell. The coverage table comes to the rescue. A record is placed in the coverage table for each product in each store that is on promotion in each time period. In general, which products are on promotion varies by all of the dimensions of product, store, promotion, and time. This complex many-to-many relationship must be expressed as a fact table.

The coverage table must only contain the items on promotion; the items not on promotion that also did not sell can be left out. Also, it is likely for administrative reasons that the assignment of products to promotions takes place periodically, rather than every day. Often a store manager will set up promotions in a store once each week. Thus we don't need a record for every product every day. One record per product per promotion per store each week will do.

Answering the question, "Which products were on promotion that did not sell?" requires a two-step application. First, consult the coverage table for the list of products on promotion on that day in that store. Second, consult the sales table for the list of products that did sell. The desired answer is the set difference between these two lists of products.