I need to get all the relationships in my SSAS cube Data Source View between Fact and Dim tables. I've around 15 Fact tables and linked dimensions to it. Is there any MDX query to get the relationship other then doing it manually
I suspect that you want to export a list of relationships between measure groups and dimensions as they are represented in the Dimension Usage tab of the cube designer. (The relationships in the DSV don't much matter unless SSAS needs to figure out how to join two tables in a SQL query it generates. You can have a cube with no DSV relationships at all. As long as the Dimension Usage tab has the right relationships then the cube will work.)
So please install the free BI Developer Extensions and run the Printer Friendly Dimension Usage Report. I believe it will contain the info you need.
I would recommend the above. If you want to look at the appropriate data management view (DMV) run the MDSCHEMA_MEASUREGROUP_DIMENSIONS DMV. It is harder to use and interpret but has what you need in terms of representing the Dimension Usage tab:
Select * from $system.MDSCHEMA_MEASUREGROUP_DIMENSIONS
Related
During the Cloud Migration of an On-Premise Microsoft SQL DB, the OLAP Cube, which is part of it, should also be replaced (but not migrated directly). There is the business requirement to keep the functionality in Tableau that you can select different measurements and dimension with their corresponding aggregations, as is possible now when connecting to the OLAP Cube in Tableau.
The underlying Data Source View includes ca. 10 tables (e.g. customer, sales, payment-method, customer-segmentation, time). So via OLAP the analysis "give me the average sales per payment method per customer-segment for every week" is a couple of clicks, in pure SQL it's already some effort.
How can you offer defined aggregations for some BigQUery tables without the user having to write the joins and aggregations by themselves, mainly because it takes much more time than simply drag & drop (SQL skills & time of query-execution are not the issue)?
The answer turns out to be pretty straight forward:
Join all source data together and write it into one flat table in BigQuery which includes the same information as the data source view in the OLAP Cube. Then Tableau connects to this table. The "measurements" logic from the cube is implemented as calculations in Tableau, the table columns are the dimensions.
Some caution needs to be applied when replicating the measurements because 1:n relations in the Data Source View result in multiplied data in the flat table. This can be solvedwith the correct use of Distinct Functions (e.g. "Distinct Count") in the measurement definition.
The table will end up quite large, but the queries on it are very fast, resulting in a performance increase compared to the OLAP Cube with the same user experience as using a cube in Tableau.
Is there anyway to know underlying relational tables and their Column used in dsv . Manually we go to DSV and check tables , but it tedious process when Cube is large .
This is useful to check Impact of changes in Relational tables on Measures
For Example : IF there is measure called [Measure]. [Number of Sales] , then I would like to see DSV and respective Relational tables .
Would the Used Columns Report in BIDS Helper be what you are looking for?
It is an open source project so if for security reasons you can't install it, compile the whole project yourself. Or at least grab the relevant code and put that snippet in your own project. Here is the relevant code.
Though I have relatively good exposer in SQL Server, but I am still a newbie in SSAS.
We are to create set of reports in SSRS and have the Data source as SSAS CUBE.
Some of the reports involves data from atleast 3 or 4 tables and also would involve Grouping and all possible things from SQL Environment (like finding the max record for a day and joining that with 4 more tables and apply filtering logic on top of it)
So the actual question is should I need to have these logics implemented in Cubes or have them processed in SQL Database (using Named Query in SSAS) and get the result to be stored in Cube which would be shown in the report? I understand that my latter option would involve creation of more Cubes depending on each report being developed.
I was been told to create Cubes with the data from Transaction Tables and do entire logic creation using MDX queries (as source in SSRS). I am not sure if that is a viable solution.
Any help in this would be much appreciated; Thanks for reading my note.
Aru
EDIT: We are using SQL Server 2012 version for our development.
OLAP cubes are great at performing aggregations of data, effectively grouping over the majority of columns all at once. You should not strive to implement all the grouping at the named query or relational views level as this will prevent you from being able to drill down through the data in the cube and will result in unnecessary overhead on the relational database when processing the cube.
I would start off by planning to pull in the most granular data from your relational database into your cube and only perform filtering or grouping in the named queries or views if data volumes or processing time are a concern. SSAS will perform some default aggregations of the data to allow for fast queries at the most grouped level.
More complex concerns such as max(someColumn) for a particular day can still be achieved in the cube by using different aggregations, but you do get into complex scenarios if you want to aggregate by one function (MAX) only to the day level and then by another function across other dimensions (e.g. summing the max of each day per country). In that case it may well be worth performing the max-per-day calculation in a named query or view and loading that into its own measure group to be aggregated by SUM after that.
It sounds like you're at the beginning of the learning path for OLAP, so I'd encourage you to look at resources from the Kimball Group (no affiliation) including, if you have time, the excellent book "The Data Warehouse Toolkit". At a minimum, please look into Dimensional Modelling techniques as your cube design will be a good deal easier if you produce a dimensional model (likely a star schema) in either views or named queries.
I would look at BISM Tabular if your model is not complicated. It compresses and stores data in memory. As for data processing I would suggest to keep all calculations and grouping in database layer (create views).
All the calculations and grouping should be done at database level atleast in form of views.
There are mainly two ways to store data (MOLAP and ROLAP). Use MOLAP storage model for deal with tables that store transactions kind of data.
The customer's expectation from transaction data (from my experience) would be to understand the sales based upon time dimension. Something like Get total sales in last week or last quarter. etc.
MDX scripts are basically kind of SQL scripts that Cube can understand. No logic should be there. based upon what Parameters are chosen in SSRS report, MDX query should be prepared. Small analytical functions such as subtotal, average can be dome by MDX but not complex calculations.
Link to DCD: http://i48.tinypic.com/29de538.png
I have this DCD to work on, with SQL Server Business Intelligence Development Studio 2008.
I have made a facttable which is a view, because I need to have some measures..
Now how do I connect my facttable to the other tables? Dont know if the should be linked to selftest, instrument or network.
It would be great to hear the correct linking, and how to do it!
Thanks a bunch!
It looks like you have Instrument (first dimension), execution date (second dimension) and a resulting status (third dimension) for each Self Test. You may generate hierarchies of Instrument Type, Group and Network to group together Instruments within ssas.
The resulting counts (NumOk, NumWarning, NumError) may be your measures. Typically, you would group these together depending on the grain of your fact (i.e. daily) to a single fact table. There is no need to create separate facts per measures, you would only create separate fact tables if the measures relate to a different set of dimensions
Try to set your source up as follows (add additional attributes as required) and follow the model through to the DSV. Suggest that you ignore hierarchies until you get the basics working within SSAS.
When we run the aggregation wizard from Visual Studio for a MOLAP cube, no aggregations are created. The graph stays flat. We tried every different scenario and setting that we could think of with no luck. Any help would be appreciated.
Things to check:
Do you have natural hierarchies in your dimensions? (Needed for optimal aggregation)
Do you have the correct attribute relations for those hierarchies? (Also, needed for optimal aggregation and performance)
Do you have non parent-child dimensions available to aggregate? (Only the key attribute will aggregate in these)
Do you have any data in your cube? (the wizard needs data to work)
Do you have partitions? (aggregations can't be created for higher levels than the partition split e.g. you can't have a year aggregation on a monthly partition)
Ensure that at least some dimension attributes have their AttributeHierarchyOptimizedState set to FullyOptimized
Check the AggregationUsage cube dimension attribute property
Also read:
What are the natural hierarchies and why they are a good thing
Influencing Aggregation Candidates (This has much more detail than here)