Author here. Just a small explanation: target audience are mostly those who would like to add OLAP to their apps with simple multi-dimensional reporting needs (see trivial hello-world example ). This release brings new star/snowflake aggregation browser which can be (roughly) considered to your analytical data as ORM framework is to your transactional data - some magic happens between your code and the database that makes your life easier.
If you need any help with model creation, you encounter any issues, have a suggestion let me know.
Interesting idea. Ofcourse, OLAP isn't just about the underlying cubes and dimensions, in the end it's about how the information is being presented to the user. There's a reason why Microsoft is so good at data warehousing, because their product is one of the best, and also extremely feature-rich from the "front end" to the back end.
OLAP isn't just about the underlying cubes and dimensions, in the end it's about how the information is being presented to the user.
You are right. Cubes, dimensions and the logical model abstraction is the very first step: physical data implementation is hidden. Cubes is young, as mentioned in my comment - front-end helpers will be coming later. I will need some help on that part.
I am not quite sure about the "feature-richness". Yes, it might sell - in environments where people barely notice wrong data in 40-page monthly report, still being content about the report exhaustiveness. From my experience, many people want just basic stuff. I am trying to make cubes as small as possible (but not smaller), however extensible. For example, the cubes will not force you to use "cube's" way of drawing charts. It will provide few examples, based on common, accessible visualising backends. Along with the examples will have possibility to plug-in your own visualisation/reporting method.
The intention is not to create competitive product to the "big ones", it is rather to create light-weight, customizable alternative for many smaller projects.
Cubes aims (at this moment) rather for tool for tool creators than tool for end users. But you never know, how the wind will change... :-)
well from my experience, working with OLAP Cubes, Microsoft is normally used when cost saving is important, its considered cheaper than competition. And the development tools are so easy to use, non-programmers can be trained to create and customize cubes.
On the front end, they only have excel, which is good, really good, but other tools have much simpler and in my opinion better clients, for example Cognos and BO
Excel is very familiar to many business users, and SSAS + Excel makes a powerful combo.
Currently I am working with a combination of PostgreSQL and Tableau, and find it a nicer environment to work with (coming from a MSSQL shop). I do not have the same automated aggregation engine supplied by SSAS, but Tableau in part makes up for that with visualization tools that require no coding on the UI side. I can focus my efforts on the data layer.
Thank you, both. If you have any questions or suggestions, drop me a line or much better: discuss it on the cubes-discuss google group . I would appreciate feedback from more experienced BI people than I am.
I would love to and actually was looking at pyTables and little bit at pandas. I am coming from RDBMS-based DWH world mostly, so it is a bit new area to me, howerver from what I've learned so far, there is huge potential. Unfortunately, currently I have no resources to do that, even I would like to see that more than RDBS backends (as there are already plenty of tools for that). Is there any way how this possibility can be supported? I would not mind working on a project for someone that would require OLAP layer on top of something "strange" and that there will be (open-source) by-product in form of a backend...
 p.s.: I am the only developer so far, and I am open for collaboration.