Is there a way to create a Cube in Mondrian Pentaho without a Star Schema? I tried to create a Cube with non-start schema, but I cannot export the Schema file for that and cannot customize the Dimensions.
More precisely I want to define multiple fact tables.
In Mondrian the Cube definition only defines one Table. So all your facts has to come from this single table.
To include facts from different tables you need to use a database view. Either a native view in your database or a Mondrian View.
I experienced massive performance differences between using a native view and a Mondrian View, because of how Mondrian structures it's SQL queries. I recommend native database views.
Related
I am using PostgreSQL and I want to create a layer of views on top of all the tables in my database schema. I will implement a 1-to-1 mapping of view to table, so these views will not have joins in them. The purpose is to provide a read-only abstraction so that I can change the underlying table structure of the database over time but control what is exposed through the views.
The question I have is when I start querying (SELECT statements only) using the views, including some complex joins and other complex query dynamics like aggregation/grouping, will PostgreSQL make use of the indexes on the underlying tables as if I was querying them directly?
I am starting with a PoC of this now. I don't have any results yet, but wanted to hear from other people's knowledge, experiences and opinions.
Yes, the engine will use available indexes and optimize the code. It will basically replace the view with its definition and build the plan.
Here you can fine some example and test it further.
In a transition from Mondrian OLAP server to Microsoft's SSAS OLAP server, I'm trying to find out where the aggregation tables fit in. The database have various fact tables, each with accompanying aggregation tables for year, month and day.
How can one design such a structure in Visual Studio? The current project is "Multidimensional and Data Mining". In cube designer, cube structure only handles measures and dimensions. Aggregations seem to not take any additional tables as parameters. I've found no help online for this issue either, most of the information is about aggregation design. The design is already in place, but how to connect it to the cube?
In Pentaho Mondrian, this was simply done in the schema xml adding aggregation tables inside cube section.
Can anyone share some thoughts on this topic?
In an SSAS Multidimensional model there's no such thing as an aggregation table (unlike in Tabular, which I believe does support them).
In SSAS MD the only storage structure is the cube. The equivalent of aggregation tables is aggregation designs, which store pre-aggregated values, as part of the cube, but not in a way that is visible and separate, as an aggregation table is.
Since your legacy system does use aggregation tables, maybe the migration would be easier if it went to MS SSAS Tabular rather than SSAS Multidimensional?
I have been trying to learn hana these past few days and have been getting some problems. So As i see SAP HANA is used for de-normalization of data(as per some tutorials that i have seen). So i make the analytic views and I have my data denormalized after making the analytical views. What next?. How do I harness/use these views to create reports for business analysis. I need to generate several reports based on this de-normalized data(which i intend to ultimately use for a website based product). Do i need to create different Anaytical views for different reports?
HANA is not for denormalization of your data. You don't have to create aggregate and denormalized tables to speed up your analytics. In a normal analytics scenario you might build these but this will result in duplicate data, double maintenance to keep these up date etc..
Instead of this you can use your normal normalized database tables as a master/transactional data foundation and then build analytic views on these. How many views have to be created for different reports depends on your actual business needs, because views contain data in many aspects so they can be reused. In case of more complex reports you can of course create calculation views to get the exact data you need.
HTH
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Why is database view used?
Since I always can use Select statement from original tables instead of creating a view and using select from it, I wonder what are benefits of using view in database?
It simplifies calls and provides a layer of indirection.
So, if you have a complex select with lots of joins, you can implement it in a view and simply call the view without need to consider all these joins. You can then reuse this view.
Additionally, if you use a view instead of a table in this manner, in the future if you need to migrate a column, you can easily do that and only require changes to the view.
There are several, but I think the main benefit is that views are the SQL implementation of logical data independence.
Build an updatable view, and applications that use the view are relatively immune to changes in the underlying tables. Change the structure of the underlying tables, update the view definition, and all applications work as if nothing had happened. (On legacy databases, there might be hundreds of applications written in dozens of languages. This is the big win.)
Other benefits (paraphrasing Chris Date)
"Automatic" security for hidden data. Restrict access to views, and you have fine-grained control over who sees what.
"DRY" capability for applications. A view can provide a simple, public interface to a complex SELECT statement, so applications can just SELECT column-list FROM my-easy-view.
Different users can see the same data in different ways.
Besides the obvious benefits that Oded mentioned, you can sometimes drastically improve speed by using materialized views. From wikipedia:
In a database management system following the relational model, a view is a virtual table representing the result of a database query. Whenever an ordinary view's table is queried or updated, the DBMS converts these into queries or updates against the underlying base tables. A materialized view takes a different approach in which the query result is cached as a concrete table that may be updated from the original base tables from time to time.
I have this script(dtsx file) on a sql 2005 server (made by some other technician), some stored procedures update tables with data from views. I can see that these views are based on other views, sometimes 4 to 5 layers thick before hitting the database tables. Would you recommend to improve this construction?
(when confronted with this script i found no documentation, so i don't know the motivation why this construction is used)
No, I would not recomend you change this, unless there is some logical, or business requirement that you change the structure.
Views on views is quite normal.
Have a read here
Using Views in Microsoft SQL Server
SQL Server Views