I've working on SSAS cube creation first time on real data(Although had little hands on experience on AdventureWorksDW08).I also have gone through the details for creating basics cube and all but have little question as to which are the pre-requisite for creating the SSAS cube .e.g (SQL TABLE SHOULD NOT HAVE NULL VALUES) etc.
I'm Tried so many times but it seems that data is not get refresh for certain result columns.
Related
I have a MDM cube with fact having just 84K records. Simple STAR schema structure. All regular relationships and no calculations or KPIs.
While trying to browse the cube by pulling 15-20 attributes from various dimensions with no filters applied, cube gives result in less than 10-12 seconds, which is awesome.
While reading the cube through Excel pivot, as soon as the attribute count goes beyond 8 or so, cube becomes slow to a point wherein if we bring in even a single attribute in column labels, it takes forever to respond, sometimes even crashes.
Has anyone faced such issue before and what could be a solution or workaround?
PS: I know for a fact that Excel creates a very complex MDX query to retrieve data from MDM cube which otherwise can be extracted using a simpler MDX.
I am using PowerBI desktop and connecting to a SSAS tabular model cube. This is working just fine, except there are three measures missing from the list of fields.
Through experimentation, I was able to determine that any measure with a MEDIAN or MEDIANX function is not being brought into PowerBI. If I use SUM, the measure will appear. I made sure to check for hidden measures but anything with those MEDIAN functions are nowhere to be found.
These are simple measures, similar to:
Median of X:=MEDIAN([X])
It would appear PowerBI is filtering out Medians on purpose, but I can't figure out why. I suppose I could make my own Median measure in the PowerBI desktop, but my clients want to be able to easily grab the measure from the cube... which kind of makes sense because that's why we built the cube in the first place, right?
Any ideas on how to fix this? Any help will be greatly appreciated.
UPDATE:
I have tried adding the measure three different ways:
Median Measure1:=MEDIAN([Column])
Median Measure2:=MEDIAN(Table[Column])
Median MeasureX:=MEDIANX(Table, [Column])
All three appear in the measures when I load the data source to a PivotTable. They all work identical.
I also connected to this data source in SSRS Report Builder and I am able to see all three measures.
I then connect to the datasource live in PowerBI Desktop. The measures are nowhere to be found. I can search for "median" and I receive no results. If I view hidden fields, they are still nowhere to be found.
I am using the following PowerBI Desktop version:
2.50.4859.502 64-bit (September 2017)
I will also add that I have other aggregate measures using the same table/column that are appearing fine in Power BI.
Our SSAS Tabular models are using SQL Server 2012 RTM (1100) compatibility level. Would this affect the measure in PowerBI?
This question was posted to the PowerBI forums and I will update this question if I get an answer on there.
I am curious about what "reporting cubes" are and how they relate to Oracle SQL ?
I read that they are similar to V-Lookup in Excel, but I'm not understanding much else.
thanks !
They're rather more than that! A Cube is an Online Analytical Processing (OLAP) database, as opposed to a normal DB which is an Online Transaction Processing (OLTP) DB. It's a database optimised for reporting - many times faster than querying an OLTP database. For example, I had a DB which took users up to 2 hours to get reports out. We put the data in an OLAP cube and the queries took less than 10 seconds.
This Wikipedia article is a reasonable place to start.
Note that most OLAP databases will not be updated in real time as the OLTP db is updated, but will have to have extracts made on a regular basis. Also, designing an OLAP db is not like designing an OLTP one. You need to analyse the queries the users are going to want, and split your data into Fact tables (the base data which is being reported) and Dimensions (how the users will want the data selected selected or summed). Not too difficult once you get your head round the idea, though.
Long-time SQL Server relational DBA building my second-ever cube in my first-ever SSAS database (using 2008 R2).
I am trying to add to that second cube a database dimension already associated with the first cube. No matter how I launch it, the Add Cube Dimension dialog lists only the dimensions that have already been associated with the second cube, not the one I want (nor any others) already associated with the first cube. Based on multiple web-search results, I was under the impression that database dimensions are designed to be added to multiple cubes within the same database, and that this should be easy. What am I missing?
I believe what I'm asking is nearly identical to the question posed here, but I haven't had the same epiphany that the original poster did. The table behind the dimension I want is already in the DSV.
I'm a few months into developing a reporting solution. Currently I am loading a relational data warehouse (Fact and Dimension tables) using SSIS. SSAS cubes and dimensions are then created from the relational Data warehouse. I then use SSRS to build reports using MDX queries.
The problem I have is that things are starting to get rather complicated trying to understand how multidimensional modelling works as well as MDX and cubes. Since the organization it's being designed for is rather small, I'm thinking that I should re-evaluate my approach.
I think maybe I should just eliminate SSAS from the picture and simply create reports that report directly off the relational data warehouse using SQL queries. The relational data warehouse could still be loaded nightly to allow up to date data for reporting.
I'm just wondering if that would be a good idea considering I'm not very experienced with data warehousing and SSAS. Also I wanted to know if keeping my relational data warehouse in dimension and fact tables would still work with SQL queries or would I need to redesign the tables. I don't want to make the decision to eliminate SSAS if that will end up causing more headaches or issues.
The reports will not include complicated calculations besides row counts and YTD percentages. For example "How many callers were male?" and "How many callers called for Product A?" Which are then broken down by month.
Any comments or suggestion are much appreciated cause I'm starting to feel rather frustrated with trying get SSAS cubes developed properly.
I was in a similar situation at my company. I had never used SSAS, and I was asked to do research on the benefits of using cubes to do some reporting. It was a pretty steep learning curve because my background is in development not data and reporting. SSAS is most useful when aggregate queries on a relational database are time consuming and if reports need to be broken down into hierarchies that an analyst can use to better understand the state of the business. Since SSAS stores aggregate info, queries of that nature are very quick. If your organization's data is small, the relational queries might be quick enough that you don't really need the benefit of storing aggregates.
Also you need to take into consideration the maintainability of using SSAS. If you're having trouble figuring out SSAS and MDX then how easy of a time will others? I tried to explain an MDX query I wrote to my boss who is experienced with SQL, but it's really quite different from relational queries. How easy is it going to be to add more complex reports?
A benefit to using SSAS is it can put the analyst in control of the report. Second, there are great tools and support. Finally, it's pretty easy to deploy and connect.
You can remove SSAS from your architecture yes because all the results you can get from an MDX query to SSAS, you can get from a T-SQL query to your datawarehouse because the cube was built reading data from the DW. BUT, bear in mind the following: the main advantage on an OLAP cube, in my point of view, are aggregations.
Very simple explanation: lets say you have a fact table called orders with 1 million orders per month. If you want to know how much you sold on that month, using sql you need to read row by row and sum the value to produce the total. That's like 1 million reads on your DB. If you have a cube, with the propper agrregations configured, you can have that value pre-calculated and pre-stored on your cube so if you need to know how much you sold on a month, you will have only one read to your cube.
Its a matter of analyse your situation, if you have a small cube, maybe aggregations are not necessary and you cna do fine with SQL, but depending on the situation, they can be very helpfull