I have a simple PowerPivot model with 2 tables:
DimDate & UserTransactions
I have defined a relationship on [Date] between the two tables.
Now, if I create multiple pivot charts in Excel based on both DimDate and UserTransactions (Axis comes from DimDate, Values come from UserTransaction), and then I decide that I want to use a slicer or a timeline tied to DimDate, should I or should I not expect that selecting an item in the slicer/timeline will filter the pivot charts?
The behavior I am seeing is no, it does not by default act upon all pivot charts - to do so, you must right click the slicer, choose "Report Connections", and then place a checkmark on each Pivot Chart that you want associated with the slicer, and they all then react to the slicer selection. This implies that the slicer is acting upon the pivot chart, and not the PowerPivot model itself.
This isn't unreasonable, and in cases could be beneficial (if you don't want all pivots tied to one slicer).
However, on the other hand, this seems a bit dangerous in that it could be extremely easy in a large model to miss associating a slicer with all pivots. Also, it seems inconsistent with the following blog post, which implies that the slicer filtering *is acting upon the PowerPivot model itself, rather than individual pivot tables.
http://tinylizard.com/power-pivot-relationships/
But the most important understanding is that any filters applied to a
lookup table are also applied to related data tables. And, the
reverse is not true. That is where the direction really matters.
It does not matter why this filter is happening. If I have a
relationship between my Calendar table and Sales[SalesDate], it does
not matter “how” a filter got applied to the Calendar table so that
Calendar[Year]=2009… the impact is that the filter will also be
applied to the data table (Sales). It could be from a slicer. It
could be because you put Year on rows. It could be because you wrote
a CALCULATE(). Anything. But, the reverse is not true. A filter on
your Sales table has no impact on your Calendar table. Relationships
have direction.
So:
Is the behavior (that slicers are tied to individual pivot tables, and not tied to the powerpivot model) I am observing the correct (and only) behavior available? You cannot apply filtering at the model level, and therefore what is implied in that blog post is technically incorrect?
Or is there possibly an alternate approach that does support filtering at the model level?
Related
I have sums of table columns as measures but for multiple tables. I combined them as sums of measures. On the pivot sheet i want to drill trough but i can't because it belongs to only one table. Are there any better solution for measure combinations? Thank You!
I assume by the "drill through" you mean what happens when you double click a cell in the pivot. Also, I assume that you've built a star schema with most of the measures in the centre table, and all the tables are keyed together.
You're not going to like this one, but the drill through is determined by the table you associate the measure with, and the records of just that table are returned; so the drill through is actually fairly limited. Each measure can be associated with any table, not just the one it uses, so if there is one table you want to drill into, you could associate all the measures with that.
But that's probably not really what you want. The only solution I've found is to create a pivot with the same slicer dependencies that contains all the fields you want on the drill down, and only those ones - so you've got a detail version of the main table on a different sheet. The other thing you might consider is shutting down the drill down functionality by creating an empty table, and associating all the measures with that.
I'm working on an app for which I'd like to do something very similar to the problem proposed in this question: How to add row-span in view-based NSTableView?
The second answer intrigues me as a clever solution, but I can't figure out how to keep the two table views in sync with each other. In particular, I don't see any obvious way to make sure that the rows in the item table view show up next to the group the correspond to. The most obvious solutions to me are:
Basing the data source of the items table on that of the group table view. So, each object in the group data source has a list of the items that belong to it, then each time the item table view needs a row, iterate through the groups, and count the items in each group until you find the one you need. This sounds horribly inefficient.
Some clever application of NSSortDescriptors on the items such that they end up sorted so the rows match up. This seems kind of magic to me, like you'd be lucky if you could get it to work deterministically.
Keep a pointer to the current group you're processing through and return the next item in the group until you've exhausted the group's items, then move on to the next group. This would depend on the table view asking for rows in sequential order. Seems like this would also be really difficult if there was any concurrency or out-of-order-ness anywhere.
All of these solutions have some pretty obvious flaws. I feel like I'm missing the "trick" here, or maybe just the giant purple elephant standing in front of me. :)
Edit: In response to rdelmar's comment, I'll add a few clarifications. For my particular case, the number of items in a group is variable — some groups could have two, others ten. The solution I'd like to find shouldn't depend on there being a fixed number of items in a group.
In terms of selection behavior, it's probably not necessary that each item in a group be selectable, but they do need to be editable. Groups will probably be edited as a whole, i.e. the user will say "I want to edit group A", which will trigger the ability to edit any field in the group or the items that belong to it. It's probably possible to use labels instead of a table view, but it seems like that would involve duplicating a lot of work the table view would give you for free (arranging views in a grid, etc).
The very first solution I came up with for this actually involved embedding a table view for the items inside each row of the group table view. So, the top-level table view would consist only of groups, then each group would have its own embedded table for displaying the items it has. I eventually gave up on that solution in hopes of finding one that involved a shorter view tree.
What is the advantages of creating hierarchy in SSAS? What are the difference between drag and drop year,month one by one and single hierarchy on browser?
Mainly:
Aggregations: If you want the sum per year and you have
aggregations per month, SSAS will sum all the monthly aggregations
instead of summing all the values on that particuallar year
Its a Microsoft best practice to add big dimensions in some sort of
hierarchy and set the AttributeHierarchyVisible property to false so
the attribute is enable to be browsed through the hierarchy but not
alone. That prevents the user of dragging a attribute with 1 million rows to the cube, which would break it
The advantages of creating a Hierarchy is that you give your users (Cube Users) a pre defined hierarchy that will be common with all users. You will be saving them a lot of time instead of having to drag and drop 3 - 4 members every time. Additionally, if you are working with PPS or any other reporting layer, your filters can work directly on the Hierarchy to offer users 1 Filter with drill down options instead of having them choose from 3 to 4 Filters. Finally, if you use PPS, Hierarchies will allow the user to perform auto drill down in PPS charts.
These are just a few of the benefits of Hierarchies, there are also some benefits related to Performance of Aggregations, More flexibility when working with Date Hierarchies and creating custom measures.
I'm tasked with creating a datawarehouse for a client. The tables involved don't really follow the traditional examples out there (product/orders), so I need some help getting started. The client is essentially a processing center for cases (similar to a legal case). Each day, new cases are entered into the DB under the "cases" table. Each column contains some bit of info related to the case. As the case is being processed, additional one-to-many tables are populated with events related to the case. There are quite a few of these event tables, example tables might be: (case-open, case-dept1, case-dept2, case-dept3, etc.). Each of these tables has a caseid which maps back to the "cases" table. There are also a few lookup tables involved as well.
Currently, the reporting needs relate to exposing bottlenecks in the various stages and the granularity is at the hour level for certain areas of the process.
I may be asking too much here, but I'm looking for some direction as to how I should setup my Dim and Fact tables or any other suggestions you might have.
The fact table is the case event and it is 'factless' in that it has no numerical value. The dimensions would be time, event type, case and maybe some others depending on what other data is in the system.
You need to consolidate the event tables into a single fact table, labelled with an 'event type' dimension. The throughput/bottleneck reports are calculating differences between event times for specific combinations of event types on a given case.
The reports should calculate the event-event times and possibly bin them into a histogram. You could also label certain types of event combinations and apply the label to the events of interest. These events could then have the time recorded against them, which would allow slice-and-dice operations on the times with an OLAP tool.
If you want to benchmark certain stages in the life-cycle progression you would have a table that goes case type, event type1, event type 2, benchmark time.
With a bit of massaging, you might be able to use a data mining toolkit or even a simple regression analysis to spot correlations between case attributes and event-event times (YMMV).
I suggest you check out Kimball's books, particularly this one, which should have some examples to get you thinking about applications to your problem domain.
In any case, you need to decide if a dimensional model is even appropriate. It is quite possible to treat a 3NF database 'enterprise data warehouse' with different indexes or summaries, or whatever.
Without seeing your current schema, it's REALLY hard to say. Sounds like you will end up with several star models with some conformed dimensions tying them together. So you might have a case dimension as one of your conformed dimensions. The facts from each other table would be in fact tables which link both to the conformed dimension and any other dimensions appropriate to the facts, so for instance, if there is an employee id in case-open, that would link to an employee conformed dimension, from the case-open-fact table. This conformed dimension might be linked several times from several of your subsidiary fact tables.
Kimball's modeling method is fairly straightforward, and can be followed like a recipe. You need to start by identifying all your facts, grouping them into fact tables, identifying individual dimensions on each fact table and then grouping them as appropriate into dimension tables, and identifying the type of each dimension.
Like any other facet of development, you must approach the problem from the end requirements ("user stories" if you will) backwards. The most conservative approach for a warehouse is to simply represent a copy of the transaction database. From there, guided by the requirements, certain optimizations can be made to enhance the performance of certain data access patterns. I believe it is important, however, to see these as optimizations and not assume that a data warehouse automatically must be a complex explosion of every possible dimension over every fact. My experience is that for most purposes, a straight representation is adequate or even ideal for 90+% of analytical queries. For the remainder, first consider indexes, indexed views, additional statistics, or other optimizations that can be made without affecting the structures. Then if aggregation or other redundant structures are needed to improve performance, consider separating these into a "data mart" (at least conceptually) which provides a separation between primitive facts and redundancies thereof. Finally, if the requirements are too fluid and the aggregation demands to heavy to efficiently function this way, then you might consider wholesale explosions of data i.e. star schema. Again though, limit this to the smallest cross section of the data as possible.
Here's what I came up with essentially. Thx NXC
Fact Events
EventID
TimeKey
CaseID
Dim Events
EventID
EventDesc
Dim Time
TimeKey
Dim Regions
RegionID
RegionDesc
Cases
CaseID
RegionID
This may be a case of choosing a solution before you've considered the problem. Not all datawarehouses fit into the star schema model. I don't see that you are aggregating any data here. So far we have a factless fact table and at least one rapidly changing dimension (cases).
Looking at what I see so far I think the central entity in this database should be the case. Trying to stick the event at the middle doesn't seem right. Try looking at it a different way. Perhaps, case, events, and case events to start.
Sorry for the long question title.
I guess I'm on to a loser on this one but on the off chance.
Is it possible to make the calculation of a calculated field in a table the result of an aggregate function applied to a field in another table.
i.e.
You have a table called 'mug', this has a child called 'color' (which makes my UK head hurt but the vendor is from the US, what you going to do?) and this, in turn, has a child called 'size'. Each table has a field called sold.
The size.sold increments by 1 for every mug of a particular colour and size sold.
You want color.sold to be an aggregate of SUM size.sold WHERE size.colorid = color.colorid
You want mug.sold to be an aggregate of SUM color.sold WHERE color.mugid = mug.mugid
Is there anyway to make mug.sold and color.sold just work themselves out or am I going to have to go mucking about with triggers?
you can't have a computed column directly reference a different table, but you can have it reference a user defined function. here's a link to a example of implementing a solution like this.
http://www.sqlservercentral.com/articles/User-Defined+functions/complexcomputedcolumns/2397/
No, it is not possible to do this. A computed column can only be derived from the values of other fields on the same row. To calculate an aggregate off another table you need to create a view.
If your application needs to show the statistics ask the following questions:
Is it really necessary to show this in real time? If so, why? If it is really necesary to do this, then you would have to use triggers to update a table. This links to a short wikipedia article on denormalisation. Triggers will affect write performance on table updates and relies on the triggers being active.
If it is only necessary for reporting purposes, you could do the calculation in a view or a report.
If it is necessary to support frequent ad-hoc reports you may be into the realms of a data mart and overnight ETL process.