I'm using MDX and Microsoft SQL Server 2008 Analysis Services. I know that in an MDX query, you can define query-scoped calculated members. (See Microsoft.com.) Is it also possible to create query-scoped dimensions, hierarchies, and/or cubes?
No, you only can have query scoped members and sets (and -nearly never used - query scoped calculations). In Essbase, but not in Analysis Services, you can also have query scoped tuples. But you cannot have any other query scoped objects in MDX.
Related
I would like to understand how OLAP-cube operations (i.e. drilling up/down, slicing/dicing and pivoting) and MDX are related.
My current guess is that OLAP-cube operations to MDX are like relational algebra to SQL. However, I do not see how some basic features of MDX correspond to OLAP-cube operations. For example, consider the following query on the demo "Sales" cube that comes with icCube:
SELECT {([Ottawa],[2009]), ([United States],[Feb 2010])} on Rows,
[Measures].members on Columns
FROM [Sales]
How does the use of tuples (e.g. ([Ottawa],[2009])) correspond to an OLAP-cube operation?
Yes, "OLAP-cube operations are what visualization tools are expected to implement". MDX is the query language that is executed against a cube that produces a result. OLAP clients generally run MDX against a cube. "OLAP cube operations" as described in that wikipedia are usually as a result of a person performing adhoc analysis against a cube in an client application.
Cube provide a structure and an access language that usually makes these types of operations easier (or at least faster)
How does MDX relate to a "drill down" operation? for example?
Firstly some MDX has already been run and yielded some kind of view of the cube (generally some rows, some columns, and a measure in the intersection although the MDX language syntax doesn't limit to two axes only).
So a person sees this information and decides to drill down on a single item in the row (this item was previously returned by some MDX). So the OLAP client generates some MDX that provides the drilled down view on the item
It might just add a children MDX function to the item in question. Or it might do it some other way. It depends on the client.
Heres some introductory info on how you can eavesdrop on the interactions between an OLAP client (which one? doesn't matter) and a SSAS cube
https://learn.microsoft.com/en-us/sql/analysis-services/instances/introduction-to-monitoring-analysis-services-with-sql-server-profiler
You can think of the MDX query specifying areas or regions of space within a cube - the tuple is a primary way of giving the processor co-ordinates which correspond to the part of the cube you are interested in.
It is the intersection of the co-ordinates and slices you specify that give you a result.
MDX is strongly related to set theory as the main types withing the cube are dimensions, sets, tuples, members etc.
An MDX query defines a table and for each of the table cell we've a tuple. In your scenario assuming we've two measures ( Meas1, Meas2 ) :
([Ottawa],[2009],[Meas1]) ([Ottawa],[2009],[Meas2])
([United States],[Feb 2010],[Meas1]) ([United States],[Feb 2010],[Meas2])
On this cell tuples you might add the WHERE clause, the SubQuery and the defaults that might be different than ALL (not advised). Remember all is a 'special' member that is ignored.
A tuple defines a single measure, Meas1 or Meas2, this will select the 'fact table' with a measure column, usually a numerical value. The other members are used to select rows in the table performing on them the aggregation defined by the measure ( sum , min, max.... ) on all rows defined by the tuple members, Ottawa and 2009 for example. As whytheq explains, you've a lot of transformations to 'play' with members as you would with sets.
This is the simple vision, as you can use calculated members that define a transformation instead of a simple row aggregation (e.g. Difference with previous year) and some aggregations are a bit more tricky ( open, close...).
But if you understand this well you got a perfect ground to understand MDX.
We are migrating from Microsoft's Analysis Services (SSAS) to HP Vertica database as our OLAP solution. Part of that involves changing our query language from MDX to SQL. We had a custom MDX query generator which allowed others to query for data through api or user interface by specifying needed dimensions and facts (outputs). Generated MDX queries were ok and we didn't have to handle joins manually.
However, now we are using SQL language and since we are keeping data in different fact tables we need to find a way how to generate those queries using same dimension and fact primitives.
Eg. if a user wants to see a client name together with a number of sales, we might take a request:
dimensions: { 'client_name' }
facts: { 'total_number_of_sales' }
and generate a query like this:
select clients.name, sum(sales.total)
from clients
join sales on clients.id = sales.client_id
group by 1
And it gets more complicated really quickly.
I am thinking about graph based solution which would store the relations between dimension and fact tables and I could build the required joins by finding shortest path between the nodes in a graph.
I would really appreciate any information on this subject including any keywords i should use searching for a solution to this type of problem or 3rd party products which could solve it. I have tried searching for it, but the problems were quite different.
You can use free Mondrian OLAP engine which can execute queries written in the MDX language on the top of relational database (RDBMS).
For a reporting you can try Saiku or Pentaho BI server on the of Mondrian OLAP.
I'm totally new to MDX language and curios if it capable of doing some sort of work.
There are calculated members that allows you to populate measure dimension with new data. But I have never met a reference to method that creates new dimensions with hierarchies.
For example, I have performed some cluster analysis and want to store result as hierarchy to make queries over calculated clusters. I'm searching for a function that takes predicate, apply it to all members in a slice and assign them new temporal dimension info. Something like the factor function in R.
Is this functionality available for MDX queries?
There is no standard way to create a dimension or hierarchies in MDX. Using calculated members is the usual way to go but this is not the same as creating a 'standard' hierarchy.
I don't know for others vendors but icCube introduced a couple of months Categories (also worth checking the SubCube functions family). They allow to dynamically, after the cube has been loaded, build new hierarchies.
This is really handy when you're doing complex calculations or have many-to-many relations, as calculated members might quickly become a mess.
I was looking at pluralsight´s SSRS-training and they used regular sql to get data to the datasets. I am just learning mdx and when I work with datasets I so far only use mdx to get data. Should/could I mix this, should I use SQL instead of mdx? I don´t want to, now that I started to enjoy mdx..
MDX is often used against multidimensional cubes and have some commands specifically for this purpose which SQL does not have. If your datasource is a database, and not a cube however SQL is most commonly used as far as I know.
Comparison of SQL and MDX: http://msdn.microsoft.com/en-us/library/aa216779%28v=sql.80%29.aspx
MDX language = OLAP Cubes (SSAS)
SQL language = Relational databases.
OLAP cubes are used for reporting and performance reasons. When data or information is needed and it involves large aggregations of data or calculations of large amounts of data from a relational database, a OALP cube can be created to sometimes better handle the demands of the data requirements. MDX is the query language used to pull data from the cube.
Here's an example to help. You need to pull some data for a report. You could use a SQL statement or a cube (MDX) for this data. You test using a SQL statement, but the query takes 5 minutes to run. Or with a cube, you could add the equivalent of the SQL statement into the cube design where it will make the equivalent of the SQL query results available instantly. How is this possible? Cube's are relational databases full of pre-run calculations and aggregations of data. Pre-run, meaning they were run or processed at some earlier time, likely at night when everyone was home.
MDX is specific to only one reporting program, SQL Server Reporting Services (SSRS). SQL is tied to multiple different database programs. Usually people who know MDX are already an expert or very familiar with SQL. I'd learn SQL first since there are many more applications for it than MDX>
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)