Comments on: Is this the Death of the Data Cube? http://havemacwillblog.com/2007/12/17/qlikview-is-this-the-death-of-the-data-cube/ Oh please, not another Mac bigot Thu, 04 Dec 2008 03:41:49 +0000 http://wordpress.org/?v=2.6.5 By: Robin Bloor http://havemacwillblog.com/2007/12/17/qlikview-is-this-the-death-of-the-data-cube/#comment-1466 Robin Bloor Tue, 13 May 2008 13:50:17 +0000 http://havemacwillblog.com/2007/12/17/qlikview-is-this-the-death-of-the-data-cube/#comment-1466 BradP I'm inclined to agree with you on this. Quite clearly Qlikview makes no contribution to the whole gamut of Master Data Management, and as far as I can tell, it was never meant to. It kicks in at the point where you have data that you want to query which is stored in some database with a schema - which is the same place that a data cube product kicks in. You can thus go through the whole datawarehouse exercise and create subject databases from the warehouse and use it on those. Alternatively you can replicate production datbases or subsets of them and group them together and use it on those. Sam's response to my article doesn't make much sense to me. BradP
I’m inclined to agree with you on this. Quite clearly Qlikview makes no contribution to the whole gamut of Master Data Management, and as far as I can tell, it was never meant to. It kicks in at the point where you have data that you want to query which is stored in some database with a schema - which is the same place that a data cube product kicks in.
You can thus go through the whole datawarehouse exercise and create subject databases from the warehouse and use it on those. Alternatively you can replicate production datbases or subsets of them and group them together and use it on those.
Sam’s response to my article doesn’t make much sense to me.

]]> By: BradP http://havemacwillblog.com/2007/12/17/qlikview-is-this-the-death-of-the-data-cube/#comment-1465 BradP Tue, 13 May 2008 12:53:12 +0000 http://havemacwillblog.com/2007/12/17/qlikview-is-this-the-death-of-the-data-cube/#comment-1465 Sam, It's hard to argue with Ralph Kimball on the academic virtues of data warehousing, but that appears to be exactly the feedback he gave you. If you asked me how to mow your lawn and I asked you 20 questions about the meaning of grass and how to effectively grow it evenly and slowly such that less mowing would be required, would you go back to the Toro and tell them they sold you a mower you didn't need? BI is not easy and NO vendor will solve all of your problems. Qliktech is trying to solve a few of them, and is doing it better than most because their solution breaks the age-old paradigm of needing large databases. Think about it for a minute...how scary is that to all the academics and BI vendors that based their entire careers on database management? It's very scary and their first reaction is to talk about process maturity, data cleansing and other BI disciplines that Qliktech never claimed to solve for you in the first place. Believe me, I spent 15 years on warehouses trying to deliver on the BI promise before I decided that one tool (or one solution) can not do it all. Warehouses have their place, big BI has its place, and now data discovery and in-memory analytics finally has its place. Here's the real value - try Qlikview and find out for yourself WHERE it fits into your BI stack and solution set. Don't let an author, vendor or consultant whose salary depends on databases tell you that it can't be done without massive warehouses. It can, and it does not replace the warehouse as a BI deliverable. It just allows you to handle parts of your BI solution in a faster, more intelligent, user friendly, agile and meaningful way (read: $$$ savings). Just like every other paradigm shift in the IT industry, most of the existing experts in legacy solutions were late adopters, and this won't be any different. Brad Sam,
It’s hard to argue with Ralph Kimball on the academic virtues of data warehousing, but that appears to be exactly the feedback he gave you. If you asked me how to mow your lawn and I asked you 20 questions about the meaning of grass and how to effectively grow it evenly and slowly such that less mowing would be required, would you go back to the Toro and tell them they sold you a mower you didn’t need?

BI is not easy and NO vendor will solve all of your problems. Qliktech is trying to solve a few of them, and is doing it better than most because their solution breaks the age-old paradigm of needing large databases. Think about it for a minute…how scary is that to all the academics and BI vendors that based their entire careers on database management? It’s very scary and their first reaction is to talk about process maturity, data cleansing and other BI disciplines that Qliktech never claimed to solve for you in the first place. Believe me, I spent 15 years on warehouses trying to deliver on the BI promise before I decided that one tool (or one solution) can not do it all. Warehouses have their place, big BI has its place, and now data discovery and in-memory analytics finally has its place.

Here’s the real value - try Qlikview and find out for yourself WHERE it fits into your BI stack and solution set. Don’t let an author, vendor or consultant whose salary depends on databases tell you that it can’t be done without massive warehouses. It can, and it does not replace the warehouse as a BI deliverable. It just allows you to handle parts of your BI solution in a faster, more intelligent, user friendly, agile and meaningful way (read: $$$ savings).

Just like every other paradigm shift in the IT industry, most of the existing experts in legacy solutions were late adopters, and this won’t be any different.
Brad

]]> By: sammoayedi http://havemacwillblog.com/2007/12/17/qlikview-is-this-the-death-of-the-data-cube/#comment-1451 sammoayedi Mon, 12 May 2008 07:13:05 +0000 http://havemacwillblog.com/2007/12/17/qlikview-is-this-the-death-of-the-data-cube/#comment-1451 I was stupefied by your comments so I test drive the software and also contacted my mentor Ralph Kimball and this what I got from him. " While I have no doubt that QlikView employs clever, appealing technology, their claims fall into the category I call “objection removers”. In other words, they sweep away all your troubles in one dramatic step in hopes that you will buy their product before you start thinking about the larger picture. What stand do they take on · Local data control (i.e. staging) both of the original extract as well as the delivered BI payload · Cleaning · Deduplicating · Conforming across multiple original sources · Establishing durable surrogate keys · Processing slowly changing dimensions (some technologies are extremely sensitive to Type 1 changes for instance) · Handling late arriving fact data as well as dimension data · Drilling down anywhere, not just declared hierarchies · Multi-valued dimensions · Ragged hierarchies Also do their claims support a multi-vendor environment using other BI ttols? You might want to read an article I wrote on this issue of objection removers. Please see http://www.intelligententerprise.com/showArticle.jhtml?articleID=167100313 . Finally, I believe there is no way to avoid a specification step somewhere in the use of any BI tool. Somewhere, you have to map the source data into the user interface of the BI tool. Every time I have looked at this step, I have concluded that the work to do this correctly is as much work as the cube or star schema building that they claim to avoid! Good luck, Ralph" So I contacted the vendor and they tried to dodge the questions and refer us to their documentation on incremental loading and saving incremental files and reuse them, so I asked for proof of concept regarding these points, the magnitude of programming involved is huge so we decided to go with our old fashioned data warehouse design, before committing to this type of claim do more research and ask for proof of concept. Sam Moayedi I was stupefied by your comments so I test drive the software and also contacted my mentor Ralph Kimball
and this what I got from him.
”
While I have no doubt that QlikView employs clever, appealing technology, their claims fall into the category I call “objection removers”. In other words, they sweep away all your troubles in one dramatic step in hopes that you will buy their product before you start thinking about the larger picture.
What stand do they take on

· Local data control (i.e. staging) both of the original extract as well as the delivered BI payload

· Cleaning

· Deduplicating

· Conforming across multiple original sources

· Establishing durable surrogate keys

· Processing slowly changing dimensions (some technologies are extremely sensitive to Type 1 changes for instance)

· Handling late arriving fact data as well as dimension data

· Drilling down anywhere, not just declared hierarchies

· Multi-valued dimensions

· Ragged hierarchies

Also do their claims support a multi-vendor environment using other BI ttols?

You might want to read an article I wrote on this issue of objection removers. Please see http://www.intelligententerprise.com/showArticle.jhtml?articleID=167100313 .

Finally, I believe there is no way to avoid a specification step somewhere in the use of any BI tool. Somewhere, you have to map the source data into the user interface of the BI tool. Every time I have looked at this step, I have concluded that the work to do this correctly is as much work as the cube or star schema building that they claim to avoid!
Good luck,
Ralph”
So I contacted the vendor and they tried to dodge the questions and refer us to their documentation on incremental loading and saving incremental files and reuse them, so I asked for proof of concept regarding these points, the magnitude of programming involved is huge so we decided to go with our old fashioned data warehouse design, before committing to this type of claim do more research and ask for proof of concept.
Sam Moayedi

]]>