The objective I am trying to achieve is to have 2 slicers in PowerPivot, ClientID and CSQName. When a ClientID is selected only the CSQnames that are related to that ClientID show up ,and vice versa
Relationship diagram link: https://goo.gl/photos/PnCZrnsXXTx3oFGh8
I am having a problem linking a many to many relationship in PowerPivot. A brief background on the application I am trying to build...
I am trying to combine a SQL database (IDM) and Informix SQL database (Cisco Call Data). The IDM database includes the Client Data and TBAS Open Case Data. Each Client has a specific ClientID. The Cisco database includes Call Detail Info and CSQNames(queue names). A many to many relationship exists, for example, a clientid can have multiple CSQname (clientid 3 has CSQ names of "A" and "B"). Also a csqname can have multiple clientids (csqname "Z" includes clientids "99", "98" and "97". Therefore I created an innerjoin table to create the many to many relationship called "Clients_CSQ".
I am trying to use this innerjoin table for both the "TBAS Open Cases" and "Call Detail". When I use this table for my filters, PowerPivot is stating that no relationships exist. Are there any solutions? If this does not make sense please let me know and I will try to specify. I have ready many posts but am unable to grasp how to make the DAX many to many relationship work with the calculate function. If someone can shed some light on the issue I am having it would be greatly appreciated. Thank you.
This really depends upon the data you are looking to report on.
When you add two slicers to a PowerPivot table, the available selections in each slicer will be affected by the selection in the other slicer IF and ONLY IF all of the fields in the Values section of the Pivot Table are reliant on the entries in both of the slicer fields.
In your case, it is possible to make this work (as an example) by creating 3 measures:
[Call Total]=SUM('TBAS Open Cases'[Case duration])
[Number of Calls]=COUNTA('Call Detail'[appname])
[Calls by Duration]=SUMX('Clients_CSQ',DIVIDE([Call Total],[Number of Calls]))
Place the last of these 3 measures in a pivot table with the slicers set to use 'Clients_IDM'[ic_client_id] and 'CSQ Name'[csqname] and "Hey Presto!"
The first two measures are straightforward enough. The third one is cycling through each entry in the only table that these two slicer fields have in common (Clients_CSQ) and performing a calculation using the data from your FACT tables. I have no idea if the [Calls by Duration] measure that I've come up with makes any sense with your data set, but hopefully the example will help you reach the solution you want. Again depending on what data you want to show it doesn't really matter if this measure returns junk, the important thing is that it's pulling your two data sets together.
Remember that as soon as you add any raw field from either of the fact tables to this 'unifying pivot table', the inter-relationship between the slicers will break. !!!BUT!!! there is nothing to stop you from linking the csqname slicer to another pivot on the same sheet which contains fields from your Call Detail table and likewise linking the ic_client_id slicer to a pivot that contains TBAS Open Cases data. In fact, the 'unifying pivot table' could be on a different sheet from your slicers, so you only see the two sets of data that you are interested in.
And ignore that warning about no relationships existing!
Related
I have Table A prompted on Year/Month and Table B. Table B also has a Year/Month column. Table A is the default data table (gets pulled in first). I have set up a relationship between Table A and B on the common Year/Month column.
The goal is to get Table B to only pull through data where the Year/Month matches the Year/Month on Table A (what the user entered). The purpose is to keep the user from entering the Year/Month multiple times.
The issue is Table B contains almost 35 million records. What I do not want to do is have Spotfire pull across all 35 Million records. What is currently happening is Spotfire is pulling all those records, then by setting filtering to include Filtered Rows Only on Table B, I am limiting what is seen in the visualization to under 200,000 rows. I would much rather just pull across 200,000 rows to start with.
The question: Is there a way to force Spotfire to filter the data table (Table B) by another data table (Table A) as it pulls the data table (Table B) across, thus only pulling a small number of records into memory?
I'm writing this off the basis that most people utilize information links to get data into Spotfire, especially large data sets where the data is not embedded in the analysis. With that being said, I prefer to handle as much if not all of the joining / filtering / massaging at the data source versus the Spotfire application. Here are my views on the best practices and why.
Tables / Views vs Procedures as Information Links
Most people are familiar with the Table / View structure and get data into Spotfire in one of 2 ways
Create all joins / links in information designer based off data relations defined by the author by selecting individual tables from the data sources avaliable
Create a view (or similar object) at the data source where all joining / data relations are done, thus giving Spotfire a single flat file of data
Personally, option 2 is much easier IF you have access to the data source since the data source is designed to handle this type of work. Spotfire just makes it available but with limited functionality (i.e. complex queries, Intellisense, etc aren't available. No native IDE). What's even better is Stored Procedures IMHO and here is why.
In options 1 and 2 above, if you want to add a column you have to change the view / source code at the data source, or individually add a column in the information designer. This creates dwarfed objects and clutters up your library. For example, when you create an information link there is a folder with all the elements associated with it. If you want to add columns later, you'll have another folder for any columns added, and this gets confusing and hard to manage. If you create a procedure at the data source to return the data you need, and later want to add some columns, you only have to change this at the data source. i.e. change the procedure. Everything else will be inherited by Spotfire... all you have to do is click the "reload data" button in Spotfire. You don't have to change anything in the information designer. Additionally, you can easily add new parameters, set default parameter properties or prompt the user, making this a very efficient method of data retrieval. This is perfect when the data source is an OLTP and not a data-mart/data-warehouse (i.e. the data isn't already aggregated / cleansed) but can also be powerful in data warehouse environments as well.
Ditch the GUI, Edit the SQL
I find managing conditions, parameters, join paths, etc a bit annoying--but that's me. Instead, when possible, I prefer to click "Edit SQL" next to all the elements in my Information Link and alter the SQL there. This will allow database guys to work in an environment which is more familiar.
I thought there would be a simple way of doing this, but unfortunately I have not come across one. My company has an Excel workbook with 12 sheets (1 for each month), into which I enter sales data as accounts are written. I reformatted each month's data into tables, thinking that this would provide an easy reference to gather the data into a pivot table that joins all the months and would be updated as I enter data; however, a pivot table based on multiple sets of data allows highly limited manipulation.
So what I want to do is create a new table that is automatically populated as I enter data in any of the 12 current tables, to combine them into a master listing. I have tried doing a query, but when I try to set up the data sources, it doesn't recognize my tables. I tried Power Query, but I couldn't get it to update the data as I updated the source. Consolidate also was not a useful feature, as it required all the data to be somehow calculated, and my columns need to simply be copied over, not summed or averaged.
As you can probably tell from my explanations and terminology, I'm no Excel expert. I don't know what VBA even is, let alone know how to use it, but I've seen it mentioned a lot, so I figure at some point in my life I should learn it.
Is there a formula or some other Excel 2010 feature that can automatically copy all of this data onto one running list, and keep it updating as I enter data in the source tables? It would have to run automatically.
I believe your end goal is to have a pivot table which consolidates data from each of the individual 12 sheets/tables and not really to have the intermediate "single running list which is an aggregation of all the 12 sheets".
If so, I suggest to create an Excel Pivot table directly based upon the 'Multiple consolidation ranges'.
To start, create a new spreadsheet and select a cell (say A3) and use the click sequence Alt+D+P, this will bring up the PivotTable and PivotChart Wizard, and proceed further using the third option - 'Mulitple consolidation ranges'.
I will have to refer you to the below site for a detailed step by step instructions on the above: http://www.contextures.com/xlPivot08.html
Please be aware that the Difficulty level for this solution is Medium, suggest you to bookmark the solution from maintainability reasons, in case you choose to implement it.
Whenever I have two tables in the same column, I get this error.
Create a table in columns (ie B1:C3)
Create another table below that table (ie B5:C7)
Right-click on column B
Is the "Delete" option grayed out (unavailable)?
Convert the second table (B5:C7) back to a normal area
Right-click on column B
Is the "Delete" option active (black) now?
It is for me.
I don't understand why it happens but I'd really appreciate if someone could confirm that I'm not alone on this one. This actually seems like a bug.
Unfortunately this is 'behavior by design'. A ListObject (aka structured ) table has many internal mechanisms. The Delete (column) command is not designed to enumerate through all of the ListObjects on the worksheet to see if any intersect with the column being deleted and then spawn subprocesses that deal with deleting table columns specifically while simultaneously keeping in mind how that will affect other ListObject tables. Instead, it simply does not allow the Delete command when more than a single ListObject table is involved.
This is not allowed may be because deleting a column will Shift Cells Why Dont you try deleting by selecting one column of a Table Like this
see the screenshot you can do it if you select one column of a table at a time
Thanks
Try organizing your data in a different way, so these problems don't occur.
There is no compelling reason to have several tables on ONE sheet. If table placement presents a problem with row/column management, consider moving tables to separate sheets.
Tables can be referenced in formulas by the table name. Ditto for table columns, so there really is no reason to keep several tables on one sheet if you need flexibility with row and column management.
Edit after comment The fact that users are working with several tables and cannot be expected to change sheets to maintain data on different sheets can be addressed in different ways:
Educate your user. I'm a big fan of teaching people how to use software. If they understand what they are doing, they feel positive. If you keep them dumb and tell them to "just click there and shut up" they may feel negative.
You may want to re-consider your data architecture. Provide your users with an interface to add/edit/delete records that is independent of where the data is stored. This is 2016. Data input and data storage are not married to the same page.
You are posting your question in a site for enthusiast programmers. A little bit of VBA will separate your data entry/data storage issues, if you are interested to work it out.
Note: I don't think it makes any fundamental difference, but I am working with pivot tables running on top of a PowerPivot model.
Example scenario:
Three tables in a model: SalesTransaction, BuyerCustomers, SellerCustomers, with a two defined PowerPivot relations:
BuyerCustomers.CustomerCode --> SalesTransaction.BuyerCustomerCode
SellerCustomers.CustomerCode --> SalesTransaction.SellerCustomerCode
I have a PivotTable defined using SalesTransaction as the data source.
Now, if I want to create slicers on both BuyerCustomer and SellerCustomer, in the Pivot Table fields window I can right click and "add as slicer" on either:
SalesTransaction.BuyerCustomerCode and SalesTransaction.SellerCustomerCode (the two columns in the transaction table)
BuyerCustomers.CustomerCode and SellerCustomers.CustomerCode (the individual lookup tables)
Either way, the behavior is identical. My question is: once this has been set up, how can one tell what a slicer is bound to via the UI in Excel? Other than being able to deduce the obvious association via column names, how does one tell?
Using VBA, one can discover the association like so:
ActiveWorkbook.SlicerCaches("Slicer_CustomerCode").SourceName
...which yields:
"[SalesTransaction].[BuyerCustomerCode]"
or
"[BuyerCustomers].[CustomerCode]"
....but as far as I can tell, there is no way to see this via the UI.
You cannot find the slicer TableName.ColumnName data source via the UI, you can only see the ColumnName.
As posted in the question, you can see both table and column names via VBA:
ActiveWorkbook.SlicerCaches("Slicer_YourSlicerName").SourceName
...which yields:
"[TableName].[ColumnName]"
Can we create category for Pivot table field list which appears in right side pane after opening a pivot table.For example normally there will be some check boxes to be selected.I want certain check boxes to come under a group or folder. I see the same functionality is supported in cubes excel reporting.Is it the way you write the queries to pull and do group by
Please help...
I'm going to go with not possible, but someone may have a fancy trick I'm not aware of. Pivot tables are fundamentally 2-dimensional, where OLAP allows multi-dimensional data. There are a number of tricks you can try with grouping data, however, that might get you part of the way to where you want to go. Here's a start.