I have a user group that wants a KPI off a measure include in their reports. There are other user groups who do not wish to have this measure included. I was thinking of creating perspectives that filters that measure from their views.
When I try to create the perspective, I do not see the KPI as an option to check. I see the column name as well as the measure as an option to filter, but not the KPI. Hence, when I go to analyze the data in excel, all of my KPIs appear as an option to include, while the measure does not.
Does anyone know how I can include a KPI in a perspective through SSAS? If this is not possible, is anyone aware of a different way to filter a KPI?
There are different types of objects that can be included in an SSAS perspective. KPIs will be in a separate section from measure groups. MSSQLTips.com has a good article about SSAS perspectives. You can see from the image in that article that KPIs are grouped together. You can expand the KPIs section and choose the ones you want to include.
If you are using perspectives, I also recommend using BIDS Helper. It has a feature called Tri-State Perspectives that highlights measure groups or dimensions that contain children that are not part of the perspective. This is helpful because new items (measures, dimension attributes, KPIs, calculations, etc.) are not included in perspectives by default.
Related
I have inherited several cubes and have learned a bit through doing maintenance and updates to the cubes. One thing I don't understand is "ordering" for measures and dimensions. I use Visual Studio 2015 and 2017 in case it matters. In the dsv, the named queries are all listed in alphabetical order which is perfect. In the cube, however, the Measures and Dimensions are not shown in alphabetical order, and I also don't see an option to sort. Why is that? I have tried to find an answer, and it seems to be to manually drag things into the desired order. But every website I find that says this also has this cryptic statement: "The order will affect how certain client applications order these measures." Does anyone know what "certain client applications" refers to? Am I going to cause trouble for myself if I move the Measures and Dimensions around so they are in alphabetical order? There are a lot of dimensions, which is why I want to do this -- I waste so much time manually looking through the list of Dimensions (there are > 70), trying to find the one I want.
The cube also has many calculations (>60), which are also not ordered. Similar question there: could it be problematic if I change the ordering there?
The cube is used by Excel users as well as by dashboards.
Update: It's been many months now since I manually reordered my cube measures and dimensions. I have found no ill effects, even with calculations, and it makes it much easier to find things. To answer the question "why," it's because my cube has 13 measure groups and about 90 dimensions, and it makes it easier for me to find things while doing active development. Yes, the ordering is automatic for Excel users but it's not automatic for developers.
We have a well established SSAS cube design in production, with a large selection of SSRS reports and ad hoc user reports available. The cube design is somewhat complex, with a large number of business rules written into the calculations.
There is a new business requirements to add what is essentially a new entity to the data. Normally this would be allowed for in the design of the cube and would fit well within the existing dimensions, specifically this a new office location within a firm hierarchy linked to all the new fact data. However, the requirement this time is that is does not roll up within the main firm hierarchies, but should be reportable in the exact same way.
My thoughts on possible solutions for this:
Add the new entity as normal like in the example, a new office. Then change all the existing MDX SSRS reports to Except() this office.
Write more cube calculations that scope the firm level of all hierarchies and exclude the new office.
Create a new cube, which is an exact duplicate of the existing cube but uses a set of views which excludes the data via SQL. Copies of required reports could be pointed at this new cube.
I'm looking for options I have possibly not thought about and guidance on the best practice approach for this further development.
Please let me know if I need to add more information.
All your listed options seem like a lot of work.
I think this change could be more easily done within the existing dimension structure itself - rather than recoding every single thing in the entire cube to cope with this one exceptional case.
If, for example, your existing hierarchy looks like this:
ALL
Region
Country
Office Location
you could assign your "special" office to a new, irreal region and country, so that your regions list might look like this:
Europe
Asia
USA
South America
Special Office
The "special" office would then only roll up into the absolute highest level of the hierarchy. If required, you could mitigate this by adding a new level to the hierarchy, between "All" and "Region" - let's call it "Company" for convenience's sake - which would look like this:
TheNormalCompany
SpecialOfficeOnly
You could then use dimension security to restrict most users to member TheNormalCompany at this level in the hierarchy (but watch out for the Visual Totals gotcha). Those who do want to see the "special office" data can be restricted to the SpecialOfficeOnly member, or granted access to both.
I'm new to MDX. I understand that MDX is a query language, not a data transformation language. However, I'm also aware that this distinction is partially meaningless; there is no clear line between transformation and reporting, and every query language is capable of some transformation. Proficiency in a query language requires knowing what transformations are reasonable, and which require a redesign of the underlying schema.
From what I've seen of MDX, it clearly has features designed for creating calculated members within a dimension. Beyond that, however, I'm not clear on its transformation capabilities. Can anyone provide a concise summary of which types of transformations MDX can reasonably be expected to do?
I don't intend for this question to be limited to my particular reporting challenge. However, by describing my project, I can illustrate a few of the transformation types I'm interested in. So, here's a description of what I'm working on:
I need to use MDX to create some inventory and sales reports. I'm working with Microsoft SQL Server 2008 Analysis Services. The data is organized into three different cubes: On-Hand Inventory, In-Transit Inventory, and Sales. My reports require that the data be transformed in several ways. For instance:
1) I need to infer a "Months" attribute from the "Weeks" attribute, using the rules of a 4-4-5 calendar. I'm fairly certain this can be done elegantly with MDX.
2) I need to infer a "Calendar Month" dimension from the "Months" attribute. I believe this can be done with MDX, but I'm not sure whether there is an elegant solution or a kludge which should be avoided in favor of a schema redesign.
3) I need to infer a "Region" dimension from the "Warehouse" dimension. I've seen no evidence that this can be done in an elegant way by MDX.
4) I need to calculate total inventory as On-Hand Inventory plus In-Transit Inventory. From searching the web, it seems that querying two different cubes is possible, but is discouraged in favor of schema redesign, but the water is still very muddy.
I would say most of your requirements can be done with Analysis Services, but not necessarily with MDX. Rather, they would be done in cube design. This is normally done using the GUI, which is Visual Studio called BIDS (Business Intelligence Development Studio). If you absolutely want to use a language, you could use XMLA, which is how BIDS communicates with the Analysis Services server. But this would still not be MDX, and is not very well documented, and hence difficult to learn. You could use .net and AMO, but the easiest way is the GUI in BIDS.
And some of your requirements would optimally be implemented in the design of the relational tables on which the cubes are based. The first three of your requirements are best implemented in the dimension tables, and then just used in the dimension objects in the cube definition. For the fourth requirement, you are right, this can easily be implemented in a calculated measure in the cube calculation script. And this, indeed, is MDX.
In theory, you could also implement the first three requirements somehow in MDX. But this would be complex, difficult to maintain and have bad performance. MDX is just not designed for tis type of requirement.
Firstly, I feel comfortable with what a hierarchy is in terms of the concept and how it impacts the design of a DW's star schema. I have some dimensions with lots of attributes, and I could create lots of hierarchies within SSAS. I would like a better understanding of how the OLAP engine uses the hierarchies that I create so that I can make a more informed decision on how I design my hierarchies(that's a tough word to type the first few times). There are also limitations with SSAS regarding attributes appearing in multiple hierachies so sometimes I have to do extra work to work around those limitations or decide which hierarchy is more important.
I also wonder what negative impacts a hierarchy might have, such as making the dimension more confusing for users. I might hide the attributes which are included in hierarchies to eliminate the duplicate attribute and make the dimension less confusing. But then a user wants to see which months of the year they typically get more sales. If I've hidden the month attribute so that it is only available through a Year->Month hierarchy, are they forced to always include the Year part of the hierarchy, preventing them from doing such analysis?
I few articles on hierarchies have stated something to the effect of "allowing the user to drill down to detailed data". Which is misleading, because you can simply drag the separate year and month attributes to a report and you've accomplished just that without the use of a hierarchy. So such an explanation is a little superficial. I feel like there must be a lot more to it than that.
Some articles seem to suggest it determines whether or not attributes are considered for aggregation. This seems counter intuitive, because I thought that already occurs when you included an attribute in a cube. I mean the whole point of creating a cube consisting of attributes, is to have an intersection of all of the attributes so that you can quickly aggregate on any combination of them, so it confuses me when something implies the opposite of that by saying only attributes in hierarchies are considered for aggregation:
Attributes only exposed in attribute hierarchies[as opposed to user
hierarchies] are not automatically considered for aggregation by the
Aggregation Design Wizard. Queries involving these attributes are
satisfied by summarizing data from the primary key. Without the
benefit of aggregations, query performance against these attributes
hierarchies can be slow.
-SSAS 2008 Performance Guide
Can someone explain how the engine uses my hierarchies in contrast with just including the attribute in the cube? (besides the aesthetics of grouping attributes together)
Unnatural hierarchies are confusing as heck to me in particular. In the SSAS 2008 Performance Guide they show one example as a Gender->Education hierarchy. I think my users would mumble "stupid programmer" every time they had to drill through Gender just to get to Education.
What rational do you follow on when and when not to create a hierarchy?
Not sure 100% the comments I will say applies to SSAS, but as we're both 100% MDX/XMLA compatible it's similar.
You may start by reading this and the many-to-many documentation.
The first difference between using hierarchies with levels and attributes is performance. You've two different scenarios for a drilldown (take [Asia] as a particular member and let's find all countries of [Asia]):
Using hierarchy with levels : [Asia].children()
Using attributes : ([Asia],[Countries])
The first option is trivial and very fast (the structure is in memory). The second one implies iterating though all countries and 'check' if they exist (aka are countries of [Asia]). This can be a pain for huge attributes (>100k). Once done, we need to go to our fact tables where each members has a set of associated fact rows. The version with a single hierarchy is again direct. The one with two might imply some additional internal operations -> all rows of [Asia] minus the ones of a particular country. Simplified version is also more handy for the cache.
Second, you define a 'natural' drilldown path that can be directly used in the GUI.
On top, you can add special aggregations types (First,Last, Min, Max...) that will take into account the structure of a given hierarchy.
There are successfully OLAP solutions that work without hierarchical structures but you've less features to play with for making a solution.
I hope it helps you understand these concepts better.
Maybe this is a shot in the dark here but I'm trying to find out if anyone has thoughts on this problem we have been presented with.
The situation is that we have a database that contains all kinds of data about a large list of projects. There are dozens of tables that all provide supporting info about a project, both in 1 to 1 manner, where some specific type of info about projects (say ProjectInfoTypeA) might be stored in a table called ProjectInfoTypeA, and we'd do a inner join between that and the projects table, as well as 1 to many, like maybe ProjectScopeKeywords, where a project can be assigned N attributes or in this case "keywords" for a number of different attribute/lookup tables.
In the end we need to have the user in our web app build up things like:
Show me all projects completed in the last 5 years that took at least 4 years to do, cost at least $1MM, and have all 3 of these keywords ( x,y,z ) associated with it.
We also want users to be able to save their queries so they, and other users, can select them from a list of saved queries.
Once we get the list of projects from their filter, we need to then work with it in all different ways: but not as a report. If this were a report I'd just give them some report builder of some kind, but we need to work with their filtered list in the web app.
Currently we are thinking of 2 different ideas:
1) being that we just try to write our own UI for building up the query, and then create some giant SQL statement.
2) we store the data about each of their filters in the database, and then when they slick "Search" we would essentially prune down the list of projects by iteratively stripping off the projects that didn't match each query, based on the data they stored in the database.
I'm guessing no one out there has had to deal with something like this, but if any of you had, I'd be interested to hear any suggestions/patterns that would be worth looking into.
I would recommend choosing option 1. I have used a query-builder approach on a number of projects, with varying degrees of sophistication depending on the complexity of the requirements.
If you are in a position to use a ready-made solution, you can find several on the web: http://www.google.com/search?q=sql+query+builder
For a custom built solution, at a minimum, you would probably want to provide flattened views for the user to query from; this will simplify the designer complexity, reduce the learning curve for the user, and provide some abstraction against future schema changes.
After defining your base data sources, you need to provide means by which the user can select specific columns, define filter criteria, specify value aggregation, and define sub-queries (based on your example query requirement). The column selection and filter definition should not be too difficult, but the value aggregation and sub-query creation would be non-trivial to define. You should be able to use the ready-made solutions as examples of how to present this functionality to the user.